integration(full pod): decouple frontend build from backend/integration CI - #75
Merged
Anthony Sligar (sligara7) merged 1 commit intoJul 1, 2026
Conversation
The full-pod end-to-end job builds and starts every service via
`docker compose up --build -d`, including the frontend. But the pod's checks
(health wait + exercise scripts) only touch the backends on 8003/8004 — the
frontend is never exercised. That coupling means a frontend-team change to
frontend/Dockerfile can break the backend/integration CI (e.g. a Dockerfile
rename or a dash-incompatible `pipefail` in a RUN step will fail the whole
"full pod end-to-end" job before any backend is tested).
Move the frontend service behind a "frontend" compose profile so it is no
longer built/started by the default `docker compose up` used in CI, while
remaining available on demand:
docker compose --profile frontend up --build
This keeps the backend/integration CI self-contained and owned by the backend
team, consistent with the frontend-ownership boundary already documented in the
root docker-compose.yml. The dev pod (integration/pods/dev), whose purpose is
frontend development and which is not run in CI, is intentionally left as-is.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Anthony Sligar (sligara7)
deleted the
fix/decouple-frontend-from-integration-ci
branch
July 1, 2026 17:41
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
The
full pod end-to-endCI job brings up the pod withdocker compose up --build -d, which builds and starts every service defined inintegration/pods/full/docker-compose.yaml— including thefrontend. However, that job only exercises the backends: the health gate waits on:8004/:8003, and every exercise step hitsconfiguration_service/direct_control/ registry. The frontend is built but never tested.That coupling means a frontend-team change can break backend/integration CI even though the frontend isn't under test. Concretely, PR #68 (a frontend SSR PR) turned the whole
full pod end-to-endjob red at the build step — first with adockerfile parse error ... unknown instruction: Containerfile(a botchedDockerfile→Containerfilesymlink), then withset -euxo pipefailfailing under/bin/sh(dash) in aRUNstep. Neither has anything to do with the backends this job is meant to validate.Fix
Gate the
frontendservice behind a Composefrontendprofile so it is no longer built/started by the defaultdocker compose upused in CI, while remaining available on demand:This keeps the backend/integration CI self-contained and owned by the backend team, consistent with the frontend-ownership boundary already documented in the root
docker-compose.yml("The frontend container is intentionally NOT defined here — that's the frontend team's responsibility").Scope / notes
integration/pods/full/docker-compose.yamlchanges (one service gainsprofiles: ["frontend"], plus header/usage comments).integration/pods/dev) — whose purpose is frontend development and which is not run in CI — is intentionally left unchanged.docker compose up --build -dnow simply skips the profiled service.Verification
Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com