4 Commits

Include renames

Author	SHA1	Message	Date
shadowdaoandClaude Sonnet 5	e050b81d6c	ci: stop re-downloading CMake/Ninja on every Windows run ... lukka/get-cmake@latest re-fetched and re-extracted CMake + Ninja on every single Windows CI run. Its own cache (routed through this act_runner's built-in cache server) reported "Cloud cache miss" on every run, even one immediately after a run that logged a successful save under the exact same key -- an incompatibility between its bundled cache client and this act_runner's cache-server implementation, not a config gap. Separately and more importantly: the archive extraction step alone measured ~7.5 minutes for a 45MB zip on this VM, consistent with Defender real-time scanning rather than raw disk I/O. Together this was the dominant cost of every Windows CI run. CMake 4.4.2 and Ninja 1.12.1 are now installed once, directly on the winvm-builder VM's system PATH (C:\BuildTools\cmake, C:\BuildTools\ ninja), sidestepping the third-party action's cache entirely rather than debugging its internals further. Both Windows jobs now just verify cmake/ninja are present and fail loudly if not, instead of silently falling back to a slow reinstall. Full detail, including how to redo this if the VM is ever rebuilt, is in README's new "Windows runner: persistent build tools" section -- this is VM state, not something git reproduces. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 09:07:23 -07:00
shadowdaoandClaude Sonnet 5	43a501c06c	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
shadowdaoandClaude Sonnet 5	85e2d08f18	ci: fix Windows step shell -- use powershell, not pwsh ... Real verification push (2b216d3) caught this: explicitly setting shell: pwsh made the Windows job fail immediately with "Cannot find: pwsh in PATH". winvm-builder only has the in-box Windows PowerShell 5.1 (powershell.exe), not PowerShell Core -- which is exactly why the original inline build.yml steps never set `shell:` at all and just relied on the implicit default. Switched both workflows' Windows steps to `shell: powershell` explicitly instead of leaving it implicit, so future edits can't reintroduce this by copying a pwsh example from elsewhere. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:15:35 -07:00
shadowdaoandClaude Sonnet 5	2b216d3d75	ci: add tag-triggered release packaging workflow ... Adds .gitea/workflows/release.yml, triggered only on a pushed v* tag, which builds all three platforms (reusing the exact same configure/build/test commands as build.yml, now factored out into .gitea/scripts/ so the two workflows can't drift), zips each platform's build/package/ output, and creates a draft Gitea Release with the archives attached. This is packaging automation only -- it does not resolve or bypass the C1 WebRTC/OpenH264 release gate documented in README.md's Status section. Nothing publishes until a human deliberately pushes a version tag (which should not happen before owner sign-off) and then explicitly publishes the resulting draft. The generated release notes lead with a restatement of the open C1 question specifically so that second step can't be taken by accident. build.yml is refactored (not rewritten) to call the same shared scripts; its job/step behavior is otherwise unchanged. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01RL8abRmgFXkVASHkkqiJbE	2026-09-07 05:06:25 -07:00