mirror of
https://github.com/rcourtman/Pulse.git
synced 2026-09-10 10:35:51 +00:00
rcourtman
065ebdb276
Across v6 rc.1 → rc.5 the published install.sh asset was the agent installer rather than the server installer, and the README's pinned ed25519 key did not verify what the pipeline actually signed. The first broke `bash install.sh --version` and the in-product Update button; the second silently failed the README's secure-install ssh-keygen step. Neither was caught by CI because every existing gate operated on the local release/ build, the Docker image, or the helm chart — nothing exercised the documented LXC/systemd install commands against the published release URL. scripts/validate-release.sh now catches asset-identity drift at build time. This workflow catches the rest of the regression class — anything that breaks the actual install at runtime — by running the documented flow end-to-end against the published release. What it does: - Downloads install.sh, install.sh.sshsig, and the linux-amd64 tarball from releases/download/<tag>/. - Extracts the README's pinned pulse-installer ed25519 key and runs the exact ssh-keygen -Y verify command from the README's secure-install snippet against the downloaded asset. - Re-checks the server-installer banner, the --version) arg handler, and the absence of the agent banner — same pins as validate-release.sh, but now against what GitHub is actually serving (not just what was built locally). - Boots jrei/systemd-debian:12 privileged, runs `bash install.sh --archive <tarball> --disable-auto-updates` from inside, waits for systemd pulse.service to become active, hits /api/health, and asserts /api/version reports the expected version. --archive mode is used rather than --version so the workflow doesn't depend on install.sh's self-refetch loop (the re-fetched bytes are the ones we already validated). Auto-updates are disabled to avoid the timer unit doing anything during the smoke run. Triggers are workflow_dispatch + workflow_call only. Wire it into create-release.yml after the next RC validates it green. Pinned in build_release_assets_test.go so silent deletion or weakening of any critical assertion (signature verify, banner check, /api/health hit, version match) trips the test.