fix(docker): drop ingest target so release stays default build stage#583
Merged
Conversation
PR #582 appended `FROM release AS ingest` at the end of the Dockerfile. deploy-to-dev.yml's `docker build` runs without `--target`, so Docker defaults to the LAST stage in the Dockerfile — silently flipped the API image to the ingest variant (CMD `npm run contrail:ingest`). New API pods on b518567 crashloop because no HTTP server binds to port 3000 and the readiness probe gets connection refused. The `ingest` target was never load-bearing: the Phase E Deployment manifest overrides `command: ["npm", "run", "contrail:ingest"]` on the single-replica ingest pod, so the same `release` image works for both roles. Dropping the extra target restores `release` as the default and unblocks the dev rollout.
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
1 participant
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.
Summary
Hotfix for dev API crashloop introduced by PR #582.
PR #582 appended
FROM release AS ingestas the last stage of the Dockerfile..github/workflows/deploy-to-dev.ymlrunsdocker buildwith no--target, so Docker defaults to the last stage in the file — the API image at tagb518567is therefore the ingest variant withCMD ["npm", "run", "contrail:ingest"].The API Deployment doesn't override CMD, so the new pod runs the ingest entrypoint, never binds port 3000, readiness probe hits
connection refused, kubelet restarts → crashloop.Dev is degraded but not down — the prior 44h pod (
49c35a4) keeps serving.Fix
Delete the
FROM release AS ingestblock. Thereleasestage becomes the default again;npm run start:prodruns by default; readiness probe passes.The ingest target was not load-bearing: Phase E's
contrail-ingestDeployment overridescommand: ["npm", "run", "contrail:ingest"]on the single-replica pod, so the samereleaseimage works for both roles.Why this slipped past CI
testande2e-testjobs buildrelational.test.Dockerfile/relational.e2e.Dockerfile, not the productionDockerfile.build-and-deployjob'sdocker build ."succeeds" — it just builds the wrong stage. No probe runs in CI to catch the no-HTTP-server image.Follow-up issue worth filing: add a CI smoke that runs the built image with the same readiness probe as the Deployment.
Test plan
git diffshows only the 9-line ingest block removed; release stage and itsCMD npm run start:produntouched.build-and-deployproduces a new ECR image; gitops bumps dev overlay; ArgoCD rolls API; new pod passes readiness within ~90s.kubectl get pods -n dev -l app=apishows 2/2 Ready, no restart loop.