Ensure run-image stack matches builder in Cloud Build

[davideme]

Summary

• add a dedicated src/java/run.Dockerfile based on the google-22 run image and running as root
• adjust src/java/cloudbuild.yaml to build and push the custom run image before invoking pack with the matching --run-image
• keep the original deployment steps for pushing the final image and updating the Cloud Run service

Testing

• Not run (not requested)

[Copilot]

Pull request overview

This PR updates the Java service’s Cloud Build pipeline to ensure the buildpack run-image stack matches the google-22 builder by introducing a dedicated run image and wiring it into pack build.

Changes:

• Add src/java/run.Dockerfile to build a custom google-22 run image (configured to run as root).
• Add src/java/cloudbuild.yaml to build/push the custom run image, then invoke pack build with --run-image pointing at it.
• Keep existing-style push and Cloud Run deploy steps for the final application image.

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
src/java/run.Dockerfile	Introduces a custom buildpacks run image based on google-22/run and sets the default user.
src/java/cloudbuild.yaml	New Cloud Build config that builds/pushes the custom run image, builds the app image via pack, pushes tags, and deploys to Cloud Run.

Comments suppressed due to low confidence (3)

src/java/cloudbuild.yaml:60

• Several environment-specific values are hardcoded in substitutions (notably _AR_PROJECT_ID and _TRIGGER_ID). This makes the config harder to reuse across projects/environments and requires repo changes when infra values change. Consider using built-in substitutions like $PROJECT_ID where possible and supplying trigger-specific values from the Cloud Build trigger configuration instead of committing them into the build config.

  _AR_PROJECT_ID: lamp-control-469416
  _SERVICE_NAME: java-lamp-control-api
  _DEPLOY_REGION: europe-west1
  _TRIGGER_ID: 8f4a8369-1721-4aab-8be3-0312e689519e
  _AR_HOSTNAME: europe-west1-docker.pkg.dev

src/java/cloudbuild.yaml:9

• The custom run image is tagged as :latest and that same mutable tag is used by later steps. In Cloud Build, overlapping builds can race and pack may pull a different run image than the one built in this build. Consider tagging the run image with $COMMIT_SHA (or $BUILD_ID) and referencing that exact tag in both the push and --run-image arguments; optionally also push :latest as a separate, non-authoritative tag.

      - src/java/run.Dockerfile
      - -t
      - $_AR_HOSTNAME/$_AR_PROJECT_ID/$_AR_REPOSITORY/$REPO_NAME/java-run:latest
      - src/java

src/java/cloudbuild.yaml:43

• $LOCATION is referenced in --update-labels but is not defined in substitutions:. With substitutionOption: ALLOW_LOOSE this will resolve to an empty string, which may result in an unhelpful (or potentially invalid) gcb-trigger-region label value. If you intended to label the trigger/region, define it explicitly (e.g., _TRIGGER_REGION) or switch to a guaranteed built-in substitution.

      - >-
        --update-labels=managed-by=gcp-cloud-build-deploy-cloud-run,gcb-trigger-id=$_TRIGGER_ID,gcb-trigger-region=$LOCATION,commit-sha=$COMMIT_SHA,gcb-build-id=$BUILD_ID
      - '--region=$_DEPLOY_REGION'

[Copilot]

Setting the container USER to root in the runtime image unnecessarily grants full privileges inside the container, increasing the impact of any code execution or container escape vulnerability. If application code or dependencies are compromised, an attacker would gain root-level control of the container, which is particularly risky in Cloud Run and other multi-tenant environments. Prefer running as the non-root user provided by gcr.io/buildpacks/google-22/run or another dedicated unprivileged user, and grant elevated capabilities only where strictly necessary.

Suggested change

USER root