.gitea/scripts/publish-release.sh

@@ -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
+# release asset.
-# any platform yet -- a human still opens it and clicks Publish once that's
+#
-# no longer true (or once they're satisfied regardless).
+# 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
+**Read the per-platform notes below before relying on this.** The module has
-is verified, and how" in \`README.md\` for exactly what has and has not been
+been loaded in the OBS GUI exactly once -- Windows, OBS 32.2.2 on Windows 11,
-checked, including which claims are backed by automated tests versus a human
+2026-09-09 -- and only "it loads and registers its source type" is confirmed
-watching OBS. This is why the release is a draft -- open it and click Publish
+there. Whether video renders correctly, A/V sync, end-to-end latency and
-once you're satisfied.
+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
+Extract the archive into your OBS plugins folder. **The directory is not the
-default locations are easy to find online -- typically
+same shape on every platform, and picking the wrong one fails silently -- OBS
-\`~/.config/obs-studio/plugins/\` on Linux, \`%APPDATA%\\obs-studio\\plugins\\\`
+logs nothing at all for a plugin it never finds:**
-on Windows, \`~/Library/Application Support/obs-studio/plugins/\` on macOS).
+
-Each archive's top-level folder already matches the shape OBS expects there,
+| Platform | Extract into |
-so extracting is the whole install step. Then in OBS: Sources -> \`+\` ->
+|---|---|
+| 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}"

.gitea/workflows/release.yml

@@ -1,14 +1,16 @@
 name: Release
 
 # Packages a build of each platform into a downloadable archive and creates
-# a (draft) Gitea Release for it, so the project owner and other directors
+# a published Gitea Release for it, so the project owner and other directors
 # can grab a ready-to-use build instead of compiling from source.
 #
 # Runs only on a pushed version tag (see `on.push.tags` below) -- never on an
-# ordinary push or PR, unlike build.yml. The release it creates is a DRAFT:
+# ordinary push or PR, unlike build.yml. The release it creates is PUBLISHED
-# it stays invisible to anyone without write access until a human explicitly
+# immediately. It used to be a draft, gated on a human clicking Publish
-# opens it and clicks Publish, since nobody has run this plugin in the OBS
+# because nobody had run the plugin in the OBS GUI on any platform; the first
-# GUI on any platform yet.
+# confirmed GUI load (Windows, 2026-09-09) retired that. The caveats that
+# remain live in the generated release notes, not in the draft flag -- see
+# .gitea/scripts/publish-release.sh.
 #
 # The actual per-platform build commands live in .gitea/scripts/ and are the
 # same scripts .gitea/workflows/build.yml uses, so this workflow can't drift
@@ -183,7 +185,7 @@ jobs:
           path: dist
 
   release:
-    name: Create Gitea Release (draft)
+    name: Create Gitea Release
     needs: [linux, macos, windows]
     runs-on: ubuntu-24.04
     permissions:
@@ -214,7 +216,7 @@ jobs:
           name: release-archive-windows-x64
           path: dist
 
-      - name: Create draft release and upload assets
+      - name: Create release and upload assets
         run: .gitea/scripts/publish-release.sh
         env:
           GITEA_TOKEN: ${{ secrets.GITEA_TOKEN }}

README.md

@@ -14,8 +14,10 @@ match the vendored LiveKit binaries, which are also Apache-2.0 — see
 
 `.gitea/workflows/build.yml` builds, tests, and uploads CI-internal build
 artifacts on every push. `.gitea/workflows/release.yml` packages a tagged
-build (`v*`) into a **draft** Gitea Release; a human still needs to open it
+build (`v*`) into a **published** Gitea Release. It created drafts until
-and click Publish.
+2026-09-09, gated on a human clicking Publish because nobody had run the
+plugin in the OBS GUI; the first confirmed GUI load retired that gate, and the
+remaining caveats live in the generated release notes instead.
 
 The plugin is **functionally complete on Linux and verified end to end there**
 (module loads into real libobs, connects to a real LiveKit server through the
@@ -78,7 +80,7 @@ scripts/livekit-dev-room.py - mints tokens for the integration test
 third_party/livekit/     - redistribution notices for the LiveKit binaries
 .gitea/scripts/          - the actual per-platform build commands, shared by build.yml and release.yml
 .gitea/workflows/build.yml    - 3-platform CI matrix (every push/PR; never publishes)
-.gitea/workflows/release.yml  - packages + creates a draft Gitea Release (only on a `v*` tag push; see Status above)
+.gitea/workflows/release.yml  - packages + publishes a Gitea Release (only on a `v*` tag push; see Status above)
 ```
 
 ## How it works