2 Commits

Include renames

Author	SHA1	Message	Date
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