4 Commits

Include renames

Author	SHA1	Message	Date
TudorandClaude Opus 5	0c901cd0d1	feat(ci): gate promotion on the image set that actually passed E2E ... Staging health polling asked only whether something answered HTTP 200 at the base URL. It could not tell the new deployment from the old one, so journeys could pass against the previous release, and concurrent merges could move the staging tags underneath a run in flight. Each staging run now mints a build ID and stamps all three images with the commit and that ID, as labels and — for frontend and backend — as a build-time JSON file that environment overrides cannot rewrite. /release.json reports both identities uncached, and scripts/ci/release.py polls for the expected pair before and after the journeys. Only then are the captured build digests tagged verified-<sha>. Promotion resolves those verified tags to immutable digests, revalidates their labels, and refuses a mixed or incomplete set before any :prod tag moves. The whole staging workflow shares one concurrency group with cancellation disabled, so releases serialise. The scripts are stdlib-only and unit-tested against mocked registry and HTTP behaviour; PR checks now run the pipeline and CI suites too. The runbook records what this cannot prove locally, and that the first rollout needs a commit built by this workflow. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-09-15 10:17:50 +01:00
TudorandClaude Fable 5	ce422e6436	fix(ci): use the Actions token, not REGISTRY_TOKEN, to read the E2E commit status ... Promotion's 'Verify the staging E2E gate' step called the Gitea commit-status API with REGISTRY_TOKEN, which has container-registry scope but no repository scope — so the API returned 403 and promotion failed. Switch to the built-in GITHUB_TOKEN (repo read scope), matching how pr-checks.yml already authenticates to the Gitea API. REGISTRY_TOKEN is still used for the docker registry login, which is its correct scope. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0146VHeLAWjDVE2B5uU67jCB	2026-07-18 16:20:03 +01:00
TudorandClaude Fable 5	6877abedeb	fix(ci): harden promote workflow — env-isolated untrusted input, main-ancestry check, concurrency guard ... Addresses the AI review findings on PR #33: - severe: the workflow_dispatch sha input was interpolated directly into the run script (shell injection with REGISTRY_TOKEN + prod webhook in scope). It now reaches the shell only via env, is rejected if it starts with '-', and is resolved locally with git rev-parse. - minor: the resolved sha must be a 40-hex ancestor of origin/main — non-main refs are refused explicitly instead of implicitly. - minor: a prod-promotion concurrency group serialises promotions (cancel-in-progress: false). Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0146VHeLAWjDVE2B5uU67jCB	2026-07-13 13:14:28 +01:00
TudorandClaude Fable 5	75e92dc7f5	ci: manual production promotion workflow with e2e-gate verification ... Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_0146VHeLAWjDVE2B5uU67jCB	2026-07-13 08:36:25 +01:00