feat(release): publish releases directly, and fix the install path in the notes
Build / macOS (macos-latest) (push) Successful in 27s
Build / macOS (macos-latest) (pull_request) Successful in 26s
Build / Linux (ubuntu-24.04) (push) Successful in 56s
Build / Linux (ubuntu-24.04) (pull_request) Successful in 54s
Build / Windows (windows-latest) (push) Successful in 4m20s
Build / Windows (windows-latest) (pull_request) Successful in 3m55s

Releases were created as drafts for one stated reason: nobody had run the
plugin in the OBS GUI on any platform, so a human had to look before anything
became visible. The first confirmed GUI load (Windows, OBS 32.2.2 on Windows
11, 2026-09-09) retired that gate, so `publish-release.sh` now posts
`"draft": False` and the workflow no longer needs a human click.

The caveats did not go away, they moved: the generated release notes now lead
with what is actually confirmed (module loads and registers its source type,
Windows only) and what is not (video rendering, A/V sync, latency, mid-show
publisher restart, Linux and macOS in the GUI at all), and the per-platform
table carries the rest.

Also fixes the third and last copy of the wrong Windows install path. The
release notes template told every downloader to extract into
`%APPDATA%\obs-studio\plugins\`, which on Windows is OBS's config directory
and is never scanned for plugins -- that is what stopped a director's
correctly-shaped install from loading. The notes now carry a per-platform
table (`C:\ProgramData\obs-studio\plugins\` on Windows), the exact finished
path, a warning about Explorer's "Extract All..." wrapper folder, and how to
confirm the load in the OBS log. Both failure modes are silent, which is
precisely why they belong in the notes.

Note the tradeoff now that nothing is held back: assets upload after the
release row is created, so a release is briefly visible with no files
attached. Called out in the script header.

Verified by rendering the heredoc with a stub tag: backslash escaping survives
into correct markdown, and the YAML parses.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01AzGnvQ6wfD7bw7PZN35ft9
This commit is contained in:
2026-09-09 16:50:44 -07:00
co-authored by Claude Opus 5
parent ee44fb6a73
commit d9f73926e4
3 changed files with 57 additions and 29 deletions
+43 -19
View File
@@ -1,9 +1,15 @@
#!/usr/bin/env bash
# Creates a (draft) Gitea Release for the tag that triggered
# Creates a published Gitea Release for the tag that triggered
# .gitea/workflows/release.yml, and uploads every archive in $DIST_DIR as a
# release asset. Draft because nobody has run this plugin in the OBS GUI on
# any platform yet -- a human still opens it and clicks Publish once that's
# no longer true (or once they're satisfied regardless).
# release asset.
#
# This used to create a DRAFT, on the grounds that nobody had run the plugin
# in the OBS GUI on any platform. That stopped being true on 2026-09-09, when
# the v0.1.0 Windows artifact loaded into OBS 32.2.2 on Windows 11 -- so the
# release publishes directly and the per-platform table below carries the
# remaining caveats instead. Assets upload AFTER the release row is created
# either way, so a release is briefly visible with no files attached; that is
# the tradeoff for not needing a human click.
#
# Required env: GITEA_TOKEN, SERVER, OWNER, REPO, TAG, SHA, DIST_DIR
# Optional env: MACOS_BUNDLE_FOUND ("true"/"false", default "false")
@@ -30,26 +36,44 @@ cat > "${NOTES_FILE}" <<EOF
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. This is why the release is a draft -- open it and click Publish
once you're satisfied.
**Read the per-platform notes below before relying on this.** The module has
been loaded in the OBS GUI exactly once -- Windows, OBS 32.2.2 on Windows 11,
2026-09-09 -- and only "it loads and registers its source type" is confirmed
there. Whether video renders correctly, A/V sync, end-to-end latency and
mid-show publisher restart are all still unverified on every platform. See
"What is verified, and how" in \`README.md\` for exactly what is 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 |
| Windows (x64) | \`streamer-tools-camera-${TAG}-windows-x64.zip\` | Built and tested by this workflow's Windows job. Confirmed to load in the OBS GUI (32.2.2 / Windows 11, 2026-09-09); nothing past module load is verified. 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} |
## Installing
Extract the archive into your OBS plugins folder for your platform (the
default locations are easy to find online -- typically
\`~/.config/obs-studio/plugins/\` on Linux, \`%APPDATA%\\obs-studio\\plugins\\\`
on Windows, \`~/Library/Application Support/obs-studio/plugins/\` on macOS).
Each archive's top-level folder already matches the shape OBS expects there,
so extracting is the whole install step. Then in OBS: Sources -> \`+\` ->
Extract the archive into your OBS plugins folder. **The directory is not the
same shape on every platform, and picking the wrong one fails silently -- OBS
logs nothing at all for a plugin it never finds:**
| Platform | Extract into |
|---|---|
| Windows | \`C:\\ProgramData\\obs-studio\\plugins\\\` -- **not** \`%APPDATA%\\obs-studio\\\`, which is where OBS keeps its config and is never scanned for plugins |
| macOS | \`~/Library/Application Support/obs-studio/plugins/\` |
| Linux | \`~/.config/obs-studio/plugins/\` |
Each archive's top-level folder already matches the shape OBS expects, so
extracting is the whole install step -- but check the result is exactly one
folder deep. Windows Explorer's "Extract All..." adds a folder named after the
zip unless you clear it from the destination box, which nests it one level too
far and is equally silent. On Windows the finished path must be:
\`\`\`
C:\\ProgramData\\obs-studio\\plugins\\streamer-tools-camera\\bin\\64bit\\streamer-tools-camera.dll
\`\`\`
To confirm it loaded, restart OBS and check Help -> Log Files -> View Current
Log for \`streamer-tools-camera\` under "Loaded Modules". Then in OBS: 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.
@@ -73,7 +97,7 @@ print(json.dumps({
"tag_name": tag,
"name": tag,
"body": notes,
"draft": True,
"draft": False,
"prerelease": False,
}))
PYEOF
@@ -87,7 +111,7 @@ RESP="$(curl -sS -f -X POST \
"${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)."
echo "Created release id ${RELEASE_ID} (published; assets upload next)."
shopt -s nullglob
ASSETS=("${DIST_DIR}"/*)
@@ -106,4 +130,4 @@ for f in "${ASSETS[@]}"; do
> /dev/null
done
echo "Done. Draft release: ${SERVER}/${OWNER}/${REPO}/releases/${RELEASE_ID}"
echo "Done. Release: ${SERVER}/${OWNER}/${REPO}/releases/${RELEASE_ID}"