| name | artifact-registry-push |
| description | Build and push the current backend MSA images for this MoruPark repository to Artifact Registry. Use when Codex needs to publish api-gateway, auth-service, goods-service, or queue-service images from local code, follow the repo's Dockerfile-based release path for auth-service, goods-service, and queue-service, use Jib for api-gateway, tag images with both `latest` and `sha-<git short sha>`, and use lightweight parallel workers to push multiple services concurrently. |
Artifact Registry Push
Use this skill for repeated backend image publishing in this repository.
Quick Start
- Read references/command-recipes.md for the exact prechecks and worker pattern.
- Compute the current short SHA once before any worker is spawned.
- Verify
gcloud authentication and confirm the target registry project is yourssu-morupark-494902.
- Resolve the strategy map before fan-out:
auth-service, goods-service, queue-service use Dockerfile; api-gateway uses Jib.
- After shared prechecks pass, spawn up to four lightweight workers, one service per worker.
- Have each worker run scripts/push-backend-image.ps1 for its owned service.
- When pushes finish, summarize which tags were published and whether follow-up Argo CD or cluster verification is still needed.
Workflow
- Confirm which of the four services need publication.
- Read the repo's image delivery inputs before execution: Dockerfile availability, Jib config, GitHub Actions tag strategy, and Argo CD image updater expectations.
- Verify shared blockers locally first: current Git SHA,
gcloud auth, target Artifact Registry path, and the service strategy map.
- Spawn lightweight workers only after shared blockers are cleared.
- Assign exactly one service to each worker:
api-gateway, auth-service, goods-service, or queue-service.
- Each worker runs the push script with the resolved strategy for its owned service.
- Workers for
auth-service, goods-service, and queue-service use Dockerfile build and push. The api-gateway worker uses Jib with registry and base-image overrides.
- If a worker fails with a shared auth or registry problem, stop and fix the shared issue before retrying the rest.
- After all workers complete, verify that the published tags include both
latest and sha-<shortsha>.
- If the goal is deployment and not just publishing, hand off to
k8s-release-verification to confirm the cluster pulled the intended image.
Guardrails
- Do not assume Jib is the canonical release path for every service; the repo's current release flow is Dockerfile-based for
auth-service, goods-service, and queue-service.
- Do not trust the default
jib.to.image values in service build.gradle.kts; override the target to asia-northeast3-docker.pkg.dev/yourssu-morupark-494902/morupark-repo-private/....
- Do not use Docker Hub base image defaults during
api-gateway Jib pushes when gcr.io/distroless/java21-debian12 is needed to avoid registry auth failures.
- Do not let multiple workers share ownership of the same service push.
- Do not assume a successful image push means Argo CD or Kubernetes deployed the image.
- Do not run the parallel worker fan-out before checking shared auth and SHA inputs locally.
References
