6 Commits

Include renames

Author	SHA1	Message	Date
enricobuehler	8f1c34c6bf	fix(ci/arch): the release-rebuild prune called a helper that cannot exist there ... The v0.25.0 rebuild published perfectly — registry has punktfunk-host 0.25.0-2 with libavcodec.so=63-64, and it resolves on a real ffmpeg-9 box — then failed its last step with prune_release_assets: command not found `. scripts/ci/gitea-release.sh` sources from the CHECKED-OUT TREE, and a release rebuild checks out the OLD TAG. So the step could only ever see the helpers that existed when that tag was cut, and the prune is gated on exactly that path: the helper was guaranteed absent in the only case that calls it. Adding it to a shared script made it look available at review time while being unreachable at run time. Only the workflow file is read from the dispatched ref, so the logic moves there, inline. Same reasoning documented at both ends, including the corollary worth knowing before the next rebuild: a PKGBUILD fix made after a tag does NOT reach a rebuild of that tag either — the packaging comes from the tag too. Verified by executing the one-liner's exact bytes out of arch.yml under /bin/sh (the shell Gitea actually uses): keeps the new -2 set and gamescope, drops the superseded -1 packages and their .sha256 sidecars, leaves other legs' .dmg/.deb untouched. The `'\n'` survives the shell quoting, which was the part worth proving. Also drops the now-dead helper from gitea-release.sh rather than leaving a function no caller can reach, and leaves a warning there against the next one.	2026-08-08 10:57:49 +02:00
enricobuehler	e044f68500	fix(ci/arch): v0.25.0 shipped a host no Arch box can install, and nothing could tell ... Arch moved FFmpeg 8 -> 9 (every libav soname +1) hours before the release. PR #108 fixed the real bug — packaging/arch/PKGBUILD now binds punktfunk-host to the sonames it actually linked, so pacman refuses an upgrade instead of bricking the install — and re-keyed ci/arch-ci.Dockerfile so the builder would carry FFmpeg 9. The tag was pushed four minutes later. arch.yml and docker.yml have no `needs:` between them, and arch.yml deliberately runs no -Syu ("the image's snapshot IS the build environment"), so the release build pulled the still-FFmpeg-8 `:latest` and published punktfunk-host 0.25.0-1 depends: libavcodec.so=62-64, libavutil.so=60-64, libavfilter.so=11-64, libavdevice.so=62-64, libswscale.so=9-64 against a world that had moved to 63/61/12/63/10. It fails safely — pacman refuses, nothing bricks — but it fails broadly: pacman prepares one transaction, so an unsatisfiable dependency of OURS stopped affected users' entire `pacman -Syu`. Nothing in the pipeline could have caught it. The existing assert proves the dep is VERSIONED; it cannot prove the version EXISTS. So two guards, plus the lever to repair a release that has already shipped: * Preflight parity — compare the builder's libav `provides` against the live repos and `-Syu` the container if they differ. The image is a cache and may lag; on this one axis it may not. Syncs into a throwaway --dbpath so the container never sits in the partial-upgrade state a bare `pacman -Sy` leaves. * Publish gate — resolve every built package with `pacman -U --print` against a PRISTINE --dbpath. Empty db means "nothing is installed", so every dependency must come from the repos exactly as on a user's box. Resolving against the builder's own installed set is what would hide this: a stale ffmpeg satisfies a stale bound. gamescope stays best-effort (dropped from the upload with a warning, never fatal). * workflow_dispatch(release_tag, pkgrel) — a published release cannot be repaired by re-running its tag: pkgrel would stay 1, which is invisible to a box that already recorded the broken build, and the workflow file at the tag can never carry inputs added after it. Dispatched from main it takes the WORKFLOW from main and the SOURCE from the tag, publishes to the stable repo at a higher pkgrel, and replaces the release-page assets (prune_release_assets: upsert replaces by NAME, and a rebuild's filenames differ, so the superseded package would otherwise stay one click away). Verified on a real ffmpeg-9 box (.21, CachyOS) rather than reasoned about: the gate rejects the published 0.25.0-1 host with the user-visible error verbatim, and passes client, web, scripting and gamescope — 0 false positives across all five artifacts. The parity snippet reads today's `provides` correctly (`-Si --dbpath` on an empty db works; pacman does not wrap fields when piped). Version logic exercised on all four paths: rebuild -> 0.25.0-2 stable, tag push and canary unchanged, pkgrel=1 refused. Ships as punktfunk-host 0.25.0-2. README gains the pacman error and what to do about it; CHANGELOG says plainly that 0.25.0's Arch packages were wrong.	2026-08-08 10:34:11 +02:00
enricobuehlerandClaude Opus 5	06ffca985d	feat(ci/release): every release asset now ships its own SHA256 sidecar ... A release page offered a DMG, an MSIX, a setup.exe, an APK and a decky zip with nothing to check them against — the download either matched what we built or it didn't, and there was no way for anyone to tell which. upsert_asset now attaches `<asset>.sha256` next to each asset, so verifying is `sha256sum -c punktfunk-1.2.3.dmg.sha256` in the download directory. Doing it in the helper rather than in the callers means all eight packaging workflows inherit it at once, and a future one can't forget. Sidecars rather than one shared SHA256SUMS: those workflows attach to the SAME release object concurrently, so a single manifest would be a read-modify-write race that silently drops whichever leg lost. One file per asset has no shared mutable state. The digest is over the file, but the name written into the sidecar is the ASSET name — callers rename on upload (Punktfunk-$VERSION.dmg), and `sha256sum -c` looks up the name it reads. The PowerShell twin writes the line byte-exactly (LF, no BOM): GNU sha256sum folds a trailing CR into the filename, so PowerShell's default CRLF would have failed every check on the box doing the verifying. Verified on both sides — bash and POSIX sh locally (`shasum -a 256 -c` passes), pwsh on the windows-amd64 runner (91 bytes, last byte 0x0A, no CR, no BOM, same digest as the bash path). Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>	2026-07-29 12:12:21 +02:00
enricobuehlerandClaude Opus 4.8	ec219763a6	fix(ci/release): make _release_notes_path POSIX-sh safe (deb/decky attach runs under dash) ... The v0.19.0 deb + decky release-attach steps source gitea-release.sh under `sh` (dash) and died with "Bad substitution" at _release_notes_path's `${BASH_SOURCE[0]:-$0}` — a bash array subscript dash rejects. So those legs never attached their assets to the release (the bash legs — apple, android, rpm — were fine, which is why the body still seeded and the DMG/.ipa attached). CI always sources this from the repo root, so resolve the notes as docs/releases/<tag>.md relative to CWD and drop $BASH_SOURCE entirely. Verified under dash. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 19:03:01 +02:00
enricobuehlerandClaude Opus 4.8	15d09a8c10	feat(ci/release): author release notes in-repo + announce stable releases to Discord ... Release notes now live in the repo at docs/releases/vX.Y.Z.md, authored during the version bump (before the tag). ensure_release (gitea-release.sh + .ps1 twin) seeds the Gitea release body from that file in the create POST, so the release is born WITH its notes instead of being created empty and PATCHed afterward. canary/rc have no file -> empty body, unchanged. New manual `announce` workflow (workflow_dispatch, tag input) re-syncs the notes file over the live release and posts a violet embed (title, notes lead-in, release-page link) to the Discord #releases channel via the DISCORD_RELEASE_WEBHOOK secret. Stable-only: a -rc tag is refused unless allow_prerelease=true. Pressing "go" is the quality gate, so a half-built or failed release is never announced. docs/releases/README.md documents the ritual; TEMPLATE.md is the skeleton. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-07-23 16:43:18 +02:00
enricobuehlerandClaude Opus 4.8	6d370f7ed9	ci(release): split canary/stable tracks + unified Gitea Releases ... A push to main publishes canary builds to canary channels (fast iteration, unchanged); a single vX.Y.Z tag releases every platform at one version to the stable channels and attaches all artifacts (.deb/.rpm/.msix/.apk/.aab/.dmg + flatpak/decky/host-installer) to one Gitea Release. Collapses the host-v*/win-v*/host-win-v* tag namespaces into v* — the channel split makes the version-shadow bug structurally impossible (canary and stable are separate repos, never a shared version line). - scripts/ci/gitea-release.{sh,ps1}: one idempotent release helper (create-or-fetch + delete-before-upload), replacing 3 copy-pasted inline blocks and fixing their latent 409-on-reupload bug; prerelease flag auto-derived from the tag (an -rc tag won't shadow "Latest") - channels: apt canary/stable distributions; rpm *-canary/base groups; flatpak canary/stable OSTree branches + a 2nd .Canary.flatpakref; generic-registry canary/ vs latest/ aliases; Play internal/alpha; Apple TestFlight vs notarized DMG - android versionName threaded through gradle (versionCode stays run_number); Apple canary = TestFlight-only (no DMG/tvOS); canary base bumped to 0.3.0 - docs: new docs-site channels.md (subscribe table + cut-a-release runbook + box migration), refreshed ci.md workflow table + packaging READMEs Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>	2026-06-21 17:26:38 +00:00