Files
obs-streamer-tools-plugin/.gitea/scripts/publish-release.sh
T
shadowdaoandClaude Sonnet 5 43a501c06c
Release / macOS (macos-latest) (push) Successful in 43s
Release / Linux (ubuntu-24.04) (push) Successful in 51s
Build / Windows (windows-latest) (push) Successful in 10m43s
Build / Linux (ubuntu-24.04) (push) Successful in 52s
Build / macOS (macos-latest) (push) Successful in 28s
Release / Windows (windows-latest) (push) Failing after 16m46s
Release / Create Gitea Release (draft) (push) Skipped
release: package archives as direct drop-ins to OBS plugin dirs
Previously each release zip mirrored build/package/ verbatim (bin/ +
data/ at the archive root), which needed a manual mkdir + cp -r into
the right OBS plugin subdirectory per the install instructions. Wrap
Linux and Windows archives in a top-level streamer-tools-camera/
directory instead -- matching AddExtraModulePaths()'s expected
<config>/obs-studio/plugins/<name>/bin/64bit + data layout -- so
`unzip -d ~/.config/obs-studio/plugins/` (or Expand-Archive to
%APPDATA%\obs-studio\plugins\ on Windows) is the entire install step.

macOS already produced the right shape (the .plugin bundle itself at
the archive's top level, since OBS wants the whole bundle directly
under plugins/, not nested under a named subdirectory) -- no packaging
change needed there, just an install-instructions rewrite plus making
that text properly conditional on MACOS_BUNDLE_FOUND like MACOS_NOTE
already was, since the old hard-coded "not yet that bundle shape" text
was stale once the macOS bundle packaging fix landed.

Verified locally: staged a fake build/package/ tree, ran the new
packaging logic, and confirmed extracting the resulting zip into a
plugins directory produces <name>/bin/64bit/... and <name>/data/...
directly. Also dry-ran publish-release.sh's notes generation for both
MACOS_BUNDLE_FOUND values to confirm the conditional install text
renders correctly.

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE
2026-09-07 08:41:44 -07:00

183 lines
7.4 KiB
Bash
Executable File

#!/usr/bin/env bash
# Creates a (draft) Gitea Release for the tag that triggered
# .gitea/workflows/release.yml, and uploads every archive in $DIST_DIR as a
# release asset.
#
# RELEASE GATE: see the README's `## Status` section and
# third_party/livekit/README.md. The WebRTC/OpenH264 attribution question
# ("C1") is unresolved -- this script does not decide that question, it just
# makes sure the generated release notes put the reminder where whoever
# publishes the draft will actually read it. Pushing a version tag is the
# human decision this whole workflow hangs off of; this script does not add
# or remove any judgment about whether that decision was the right one.
#
# Required env: GITEA_TOKEN, SERVER, OWNER, REPO, TAG, SHA, DIST_DIR
# Optional env: MACOS_BUNDLE_FOUND ("true"/"false", default "false")
set -euo pipefail
: "${GITEA_TOKEN:?}"
: "${SERVER:?}"
: "${OWNER:?}"
: "${REPO:?}"
: "${TAG:?}"
: "${SHA:?}"
: "${DIST_DIR:?}"
MACOS_BUNDLE_FOUND="${MACOS_BUNDLE_FOUND:-false}"
if [ "${MACOS_BUNDLE_FOUND}" = "true" ]; then
MACOS_NOTE="This archive contains a \`.plugin\` bundle."
MACOS_INSTALL_HEADING="### macOS (installation path not yet verified in real OBS)"
MACOS_INSTALL_BODY="OBS on macOS loads plugins as \`<name>.plugin\` bundles under
\`~/Library/Application Support/obs-studio/plugins/\`. This archive already
has that shape at its top level -- extract it straight there:
\`\`\`
unzip streamer-tools-camera-${TAG}-macos.zip \\
-d ~/Library/Application\\ Support/obs-studio/plugins/
\`\`\`
No manual copying required. This has not been confirmed against a real OBS
install on macOS -- report back if you try it."
else
MACOS_NOTE="This archive is packaged as a bare \`streamer-tools-camera.so\` (the layout \`build/package/\` currently produces on macOS), **not** an OBS.app-loadable \`.plugin\` bundle. It will not load in the OBS GUI as-is."
MACOS_INSTALL_HEADING="### macOS (installation path not yet verified in real OBS; packaging gap)"
MACOS_INSTALL_BODY="OBS on macOS loads plugins as \`<name>.plugin\` bundles under
\`~/Library/Application Support/obs-studio/plugins/\`. As of this release,
this project's \`build/package/\` output on macOS is **not yet that bundle
shape** -- see the \"macOS packaging gap\" section of \`README.md\`. Treat the
macOS archive here as a build-verification artifact, not a working
drop-in, until that gap is closed."
fi
NOTES_FILE="$(mktemp)"
cat > "${NOTES_FILE}" <<EOF
> **This build has not been cleared for redistribution.** The plugin
> statically/dynamically pulls in Google WebRTC and OpenH264 code through the
> LiveKit SDK, and whether that can be redistributed as a public download --
> the "C1" attribution/patent question -- has not been resolved. Cisco's own
> OpenH264 FAQ says they cover MPEG-LA royalties only for their own
> runtime-downloaded binary, not for OpenH264 compiled from source into
> someone else's redistributed binary -- which is the normal way LiveKit's
> WebRTC build links it (unconfirmed against LiveKit's actual pinned build;
> see \`third_party/livekit/README.md\`'s 2026-09-07 section for exactly
> what is and isn't verified). See the \`## Status\` section of
> \`README.md\` for the rest. By publishing this release, you are personally
> taking on that open question -- if C1 hasn't been signed off on, don't
> publish it.
>
> (The separate GPLv2/Apache-2.0 license-compatibility question, "C2", is
> resolved: this project's own first-party code is Apache-2.0, matching the
> vendored LiveKit binaries.)
>
> This release was created as a **draft**. It stays invisible to anyone
> without write access to this repo until someone with write access opens it
> here and clicks Publish -- a second, deliberate step past pushing the tag.
# streamer-tools Camera Plugin -- ${TAG}
Built from commit \`${SHA}\`.
**Nobody has yet run this plugin in the OBS GUI, on any platform.** See "What
is verified, and how" in \`README.md\` for exactly what has and has not been
checked, including which claims are backed by automated tests versus a human
watching OBS.
| Platform | Archive | Notes |
|---|---|---|
| Linux (x64) | \`streamer-tools-camera-${TAG}-linux-x64.zip\` | Functionally complete and verified end to end against a real LiveKit server and a real libobs (see README); OBS GUI itself still unverified |
| Windows (x64) | \`streamer-tools-camera-${TAG}-windows-x64.zip\` | Built and tested by this workflow's Windows job; the WinHTTP backend has never been exercised against a real streamer-tools server, only a loopback test server -- see README's Windows CI section |
| macOS | \`streamer-tools-camera-${TAG}-macos.zip\` | Built and tested by this workflow's macOS job. ${MACOS_NOTE} See the "macOS packaging gap" in README |
## Installing
Every archive is now shaped as a straight drop-in for its platform's OBS
plugins directory -- extract it directly there, no manual copying of
subfolders required.
### Linux
\`\`\`
mkdir -p ~/.config/obs-studio/plugins
unzip streamer-tools-camera-${TAG}-linux-x64.zip -d ~/.config/obs-studio/plugins/
\`\`\`
Start OBS, then Sources -> \`+\` -> "streamer-tools Camera" -> fill in the
server URL, room slug and read key from the room's settings page ->
"Refresh camera list" -> pick a camera. Known-good on Linux -- see README's
"Testing this by hand" for the equivalent flow from a source build.
### Windows (installation path not yet verified in real OBS)
Per \`AddExtraModulePaths()\` in obs-studio's \`UI/window-basic-main.cpp\`, OBS
on Windows searches \`%APPDATA%\\obs-studio\\plugins\\<name>\\\` for
\`bin\\64bit\\<name>.dll\` plus a sibling \`data\\\`. This archive already has
that \`<name>\\bin\\...\`/\`<name>\\data\\...\` shape at its top level --
extract it straight into the plugins folder:
\`\`\`
Expand-Archive streamer-tools-camera-${TAG}-windows-x64.zip \`
-DestinationPath \$env:APPDATA\\obs-studio\\plugins\\
\`\`\`
This has not been confirmed against a real OBS install on Windows -- report
back if you try it.
${MACOS_INSTALL_HEADING}
${MACOS_INSTALL_BODY}
## What this is
Native OBS Studio source plugin that pulls streamer-tools camera feeds
directly from LiveKit over WebRTC. See \`README.md\` in the repository for
the full design, what is and is not verified, and current CI status.
EOF
echo "----- release notes -----"
cat "${NOTES_FILE}"
echo "--------------------------"
BODY_JSON="$(python3 - "$TAG" "$NOTES_FILE" <<'PYEOF'
import json, sys
tag, notes_file = sys.argv[1], sys.argv[2]
with open(notes_file) as f:
notes = f.read()
print(json.dumps({
"tag_name": tag,
"name": tag,
"body": notes,
"draft": True,
"prerelease": False,
}))
PYEOF
)"
echo "Creating release for tag ${TAG} ..."
RESP="$(curl -sS -f -X POST \
-H "Authorization: token ${GITEA_TOKEN}" \
-H "Content-Type: application/json" \
-d "${BODY_JSON}" \
"${SERVER}/api/v1/repos/${OWNER}/${REPO}/releases")"
RELEASE_ID="$(python3 -c 'import json,sys; print(json.load(sys.stdin)["id"])' <<<"${RESP}")"
echo "Created release id ${RELEASE_ID} (draft)."
shopt -s nullglob
ASSETS=("${DIST_DIR}"/*)
if [ "${#ASSETS[@]}" -eq 0 ]; then
echo "::error::no archives found in ${DIST_DIR} -- nothing to upload."
exit 1
fi
for f in "${ASSETS[@]}"; do
name="$(basename "${f}")"
echo "Uploading ${name} ..."
curl -sS -f -X POST \
-H "Authorization: token ${GITEA_TOKEN}" \
-F "attachment=@${f}" \
"${SERVER}/api/v1/repos/${OWNER}/${REPO}/releases/${RELEASE_ID}/assets?name=${name}" \
> /dev/null
done
echo "Done. Draft release: ${SERVER}/${OWNER}/${REPO}/releases/${RELEASE_ID}"