feat: add shared registry push

[scottlee01818]

Summary

This adds steps to push to the wanaware-shared project in GCP.

Why

This is required so that the operator being developed in the wanaware-operator project has appropriate permissions to pull and run the images required.

QA Report

• No QA report required

Integration Tests

• No integration tests required

Added

• Added 5 new steps to build and push (auth, docker setup, build/push)
• Steps are allowed to fail as to not affect existing workflows
• Shared push is added in front of normal push so that the last GCP account login wins to not affect followon steps

Edited

Dependencies

• New GCP_SERVICE_ACCOUNT_SHARED GitHub Actions secret
• New GCP_WORKLOAD_IDENTITY_PROVIDER_SHARED GitHub Actions secret
• New GCP_PROJECT_SHARED GitHub Actions secret
• New GCP_REGISTRY_SHARED GitHub Actions secret

[greptile-apps]

Greptile Summary

This PR adds steps to push built Docker images to a separate shared GCP project registry so that a wanaware-operator service can pull and run them. The changes restructure the existing auth/build/push sequence to authenticate with the shared GCP account first, tag the already-built image for the shared registry, push it, then re-authenticate with the standard account to proceed as before.

• Adds four new required: false secrets (GCP_SERVICE_ACCOUNT_SHARED, GCP_WORKLOAD_IDENTITY_PROVIDER_SHARED, GCP_PROJECT_SHARED, GCP_REGISTRY_SHARED) to the workflow_call secrets block; all shared steps use continue-on-error: true to avoid breaking existing callers.
• Uses docker tag to retag the already-built standard image for the shared registry (avoiding a full rebuild), then pushes to the shared registry before re-authenticating with the standard GCP account.
• The standard GCP auth and gcloud auth configure-docker have been moved to after the Docker build step, removing the credential configuration that was previously available during the build.

Confidence Score: 3/5

Safe to merge only if no calling Dockerfile uses a private base image from the standard GCP registry; otherwise every build referencing a private FROM image will fail.

The restructuring moved gcloud auth configure-docker to after the Docker build step. Any Dockerfile that pulls a private base image from the standard registry at build time will now fail with an auth error, a regression from pre-PR behaviour.

.github/workflows/deployment.yaml — specifically the ordering of the standard configure-docker step relative to the Build Docker image step.

Important Files Changed

Filename	Overview
.github/workflows/deployment.yaml	Adds shared GCP registry push via docker tag + re-auth pattern; all 4 new secrets are correctly declared as required:false, but the standard gcloud configure-docker was moved to after the build step, removing credentials for private base-image pulls during the build.

Comments Outside Diff (1)

1. .github/workflows/deployment.yaml, line 176-187 (link)

   Build step runs before standard GCR credentials are configured

   gcloud auth configure-docker ${{ secrets.GCP_REGISTRY }} has moved to line 230 — after the build step — so the Docker build no longer has the standard registry's credential helper registered. Any Dockerfile in a calling repo that uses FROM ${{ secrets.GCP_REGISTRY }}/${{ secrets.GCP_PROJECT }}/... (a private base image from the standard GCR project) will fail to pull that image at build time with an auth error. Prior to this PR, the standard configure-docker ran before the build. The only pre-build docker credential now is the shared registry (line 157), which won't satisfy pulls from the standard registry host.

_{Reviews (3): Last reviewed commit: "fix: change shared registry values to op..." | Re-trigger Greptile}

[muhammad-tahir-nawaz]

Left a few comments. Main concern is that this isn't additive as-is - the standard auth block moving after the build changes behaviour for existing callers.

[muhammad-tahir-nawaz]

This isn't additive - the standard Authenticate with GCP / Set up gcloud / configure-docker block has been moved from before the build to after Trivy. Since the shared auth that now precedes the build is continue-on-error: true, any repo that hasn't set the four _SHARED secrets will reach Build Docker image with no gcloud credentials and no docker credential helper configured at all. Any Dockerfile with a FROM ${GCP_REGISTRY}/... base image, or any build pulling from GAR, will break where it works today.

Can we keep the original standard-auth block in its original position (before the build) and add the shared auth block as new steps after the build, right before the shared tag/push, then re-auth to standard before Push Docker image? That keeps the change genuinely additive for every existing caller.

[muhammad-tahir-nawaz]

Related to the above: google-github-actions/auth writes GOOGLE_APPLICATION_CREDENTIALS into the workspace and gcloud auth configure-docker writes ~/.docker/config.json. On ephemeral ARC pods that's re-created per run so re-authenticating is clean, but on a non-ephemeral self-hosted runner the shared credentials could linger between runs and leak into an unrelated job. Can you confirm every consumer of this reusable workflow is on ephemeral runners?

[muhammad-tahir-nawaz]

Small clarity point - this comment sits above Trivy but the retag happens before it and the shared push after it. Worth rewording to say the scan gates both pushes, so it's clear the shared image is covered by the same gate rather than being scanned separately.