Skip to content

fix(deploy): add frontend build-SHA verification#105

Merged
prellr merged 2 commits into
mainfrom
fix/frontend-build-sha-verify
May 16, 2026
Merged

fix(deploy): add frontend build-SHA verification#105
prellr merged 2 commits into
mainfrom
fix/frontend-build-sha-verify

Conversation

@prellr
Copy link
Copy Markdown
Owner

@prellr prellr commented May 16, 2026

Summary

Closes the frontend-only-deploy verification gap surfaced by ROA-264 ("deployed but the change isn't there").

The deploy pipeline's correctness gate (Verify build SHA matches the running container, PR #54) only checked the backend /build_info. A frontend-only PR has no real deploy-time verification: the backend check passes trivially when the backend didn't change, and the frontend's only gate is "returns HTTP 200" — which a stale frontend image also satisfies. So a frontend image that failed to rebuild could ride through a fully green deploy unnoticed.

Fix — mirror the backend pattern on the frontend

  • apps/web/app/build_info/route.ts — App Router route handler returning {commit, version}. force-dynamic so it reads the container's runtime ENV, not a value frozen at next build.
  • Dockerfile.webARG/ENV BUILD_COMMIT in the runner stage (re-declared because ARGs don't cross build stages).
  • docker-compose.selfhost.build.yml — pass BUILD_COMMIT from MULTICA_BUILD_COMMIT to the frontend build, mirroring the backend's COMMIT arg.
  • deploy-production.yml — new "Verify frontend build SHA" step after the backend one; identical logic against the frontend port. commit='unknown' or a mismatch is a hard deploy failure.

Net: every deploy now verifies both containers serve the SHA that was built.

Test plan

  • @multica/web typecheck clean (tsc --noEmit)
  • deploy-production.yml + docker-compose.selfhost.build.yml valid YAML
  • CI green
  • On deploy: new "Verify frontend build SHA" step logs Verified: running frontend serves <sha>
  • Self-test: this very deploy exercises the new gate (frontend rebuilds → must report the deployed SHA, not "unknown")

🤖 Generated with Claude Code

The deploy pipeline's correctness gate (`Verify build SHA matches the
running container`, PR #54) only checked the backend /build_info. A
frontend-only PR (e.g. ROA-264) had NO deploy-time verification: the
backend check passes trivially when the backend didn't change, and the
frontend's only gate was "returns HTTP 200" — which a stale frontend
image also satisfies. So a frontend image that failed to rebuild could
ride through a fully green deploy unnoticed ("deployed but the change
isn't there").

Close the gap by mirroring the backend pattern on the frontend:

- apps/web/app/build_info/route.ts — App Router route handler
  returning {commit, version}; force-dynamic so it reads the runtime
  ENV, not a build-time-frozen value.
- Dockerfile.web — ARG/ENV BUILD_COMMIT in the runner stage
  (re-declared because ARGs don't cross stages).
- docker-compose.selfhost.build.yml — pass BUILD_COMMIT from
  MULTICA_BUILD_COMMIT to the frontend build, mirroring the backend
  COMMIT arg.
- deploy-production.yml — new "Verify frontend build SHA" step after
  the backend one, identical logic against the frontend port;
  commit='unknown' or mismatch is a hard deploy failure.

Net: every deploy now verifies BOTH containers serve the SHA that was
built. Frontend-only changes can no longer pass green while serving
stale code.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
@prellr prellr merged commit cbe4325 into main May 16, 2026
2 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant