Every workflow action is pinned to a commit SHA, dependabot auto-merge
is limited to patch and minor updates behind the now-required status
checks on main, and the audit, Trivy and ESLint gates block instead of
warning. The published image finally carries its build SHA and build
timestamp so the version endpoint can prove which commit is running.
The API-token HMAC key fails closed under 32 characters, compose pins
the database minor and denies privilege escalation, and the changelog
drops working-note references in favour of neutral wording.
Informational reachability gate that runs after `Build & Publish
Docker Image` finishes a `main` (or tag) build. Triggered via
`workflow_run` so it always observes the actual completion state of
the build, then:
1. pulls `ghcr.io/${repo}:${tag}` (proves the manifest finished
publishing — the v1.4.14 main run "succeeded" from a wall-clock
POV but the image had to be retagged on the deploy host because
main's manifest never finished pushing; this catches that)
2. boots the container against an ephemeral Postgres service
3. probes `/api/version` (smoke for the build SHA + version slug)
4. probes `/api/health` (smoke for the runtime DB/worker probes)
Every probe runs `continue-on-error: true` — this workflow is
informational, not a deploy gate. A transient registry blip should
surface as a yellow run, not block subsequent builds.
Also wired up `workflow_dispatch` with an `image_tag` input so we
can spot-verify any tag (`v1.4.15`, `v1.4.14`, etc.) on demand
without re-publishing.
Marc-status: filed as proof-of-concept for v1.4.15 phase-C2's
auto-deploy work — Coolify webhook listener can build on top of
the same boot harness.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
dependabot[bot]