artifact-registry-push

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

1. Read references/command-recipes.md for the exact prechecks and worker pattern.
2. Compute the current short SHA once before any worker is spawned.
3. Verify gcloud authentication and confirm the target registry project is yourssu-morupark-494902.
4. Resolve the strategy map before fan-out: auth-service, goods-service, queue-service use Dockerfile; api-gateway uses Jib.
5. After shared prechecks pass, spawn up to four lightweight workers, one service per worker.
6. Have each worker run scripts/push-backend-image.ps1 for its owned service.
7. When pushes finish, summarize which tags were published and whether follow-up Argo CD or cluster verification is still needed.

Workflow

1. Confirm which of the four services need publication.
2. Read the repo's image delivery inputs before execution: Dockerfile availability, Jib config, GitHub Actions tag strategy, and Argo CD image updater expectations.
3. Verify shared blockers locally first: current Git SHA, gcloud auth, target Artifact Registry path, and the service strategy map.
4. Spawn lightweight workers only after shared blockers are cleared.
5. Assign exactly one service to each worker: api-gateway, auth-service, goods-service, or queue-service.
6. Each worker runs the push script with the resolved strategy for its owned service.
7. 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.
8. If a worker fails with a shared auth or registry problem, stop and fix the shared issue before retrying the rest.
9. After all workers complete, verify that the published tags include both latest and sha-<shortsha>.
10. 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

• Commands and worker pattern: references/command-recipes.md
• Push helper: scripts/push-backend-image.ps1