fix(deploy-prod): push to ghcr.io — the fleet left ECR a while ago#1003
Conversation
v1.0.0's approved deploy failed at 'Log in to Amazon ECR':
checkin-deploy-prod has no ecr:* permissions — CORRECTLY, per its own
policy comment ('images are built/pushed to ghcr.io... the deploy role no
longer needs ecr:*'). The prod task definition already pulls
ghcr.io/innovationtreehouse/checkin-prod via the shared
ghcr-pull-credentials secret; this workflow was the only piece still
targeting the vestigial ECR registry (latent: first prod deploy ever).
Mirrors deploy-dev.yml: docker/login-action with GITHUB_TOKEN,
packages:write permission, IMAGE_REPO env, both :sha and :release tags
pushed. Note the accepted trade-off: GHCR has no ECR-style immutable
tags — unique :sha tags remain the practice, matching the whole fleet.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01Hq9naXJVyJnLYpFZapZW24
Full audit of the never-exercised deploy job against live AWS + the proven deploy-dev.yml found three more guaranteed first-run failures: 1. docker build had no -f: there is NO root Dockerfile — the image builds from checkin-app/Dockerfile with repo-root context (deploy-dev's exact invocation, incl. the NEXT_PUBLIC_GIT_SHA build-arg prod also lacked). 2. update-service never set --desired-count: the service is STAGED at 0 by infra (ignore_changes; 'the deploy pipeline scales this up') — a 0/0 service is instantly 'stable', so the run would go green serving nothing. 3. No post-rollout smoke existed (the header's 'smoke' is CI's image-boot check): added a real probe of APP_URL with retries, failing the run unless production actually answers. Verified clean in the same audit: capacity-provider name + strategy match the live cluster; migrate run-task pattern (host/EC2, no network config); log-dump group/stream names; host port 4000 clear of wiki; DDL secret wiring; report step. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Hq9naXJVyJnLYpFZapZW24
|
Scrubbed the whole deploy job per review — three more guaranteed first-run failures found and fixed on this branch: (1) |
✅ Deployed to devCommit
|
2 participants
The failure
v1.0.0's approved deploy failed at
Log in to Amazon ECR:checkin-deploy-prodis not authorized forecr:GetAuthorizationToken— and that's correct: the role's own policy comment says "Images are built/pushed to ghcr.io by the checkin CI… the deploy role no longer needs ecr:*". The prod task definition already pullsghcr.io/innovationtreehouse/checkin-prod(verified live:image: ghcr.io/innovationtreehouse/checkin-prod:bootstrap,repositoryCredentials: ghcr-pull-credentials). The workflow was the last piece of the fleet still pointed at the vestigial ECR registry — latent because this was the first prod deploy ever.Fix (mirrors deploy-dev.yml)
IMAGE_REPO: ghcr.io/innovationtreehouse/checkin-prodreplaces the ECR registry/repo envsdocker/login-actionwithGITHUB_TOKENreplacesamazon-ecr-login;packages: writeadded to permissions:shaand:<release-tag>tags still pushed; report step updatedTrade-off note (security review L3): ECR's IMMUTABLE tag setting doesn't exist on GHCR — unique
:shatags remain the integrity practice, consistent with the entire fleet (dev, arbor, s-read, bootstrap). Infra follow-up available: delete the now-unusedaws_ecr_repository.checkinresources.After merge
Third cut of v1.0.0 (the release workflow runs from the tag's commit). Validate + gate will re-run; reviewer approves once more; deploy proceeds on GHCR.
🤖 Generated with Claude Code
https://claude.ai/code/session_01Hq9naXJVyJnLYpFZapZW24