Just built an image using jib but hit a small issue, I am using aero and overrides specified via ENV but the ENV is not available in cloud run I can attach a .env file to the file system. I was curious how others handle this in the context of GCP and containers the ENV is all stored in the GCP secret store currently.

# Helper to load the env into the running shell, this is mainly for cloud run to avoid exposing each one individually.
if [ -f /app/environment/.env ]; then
  echo "Detected env file applying."
  export $(grep -v '^#' /app/environment/.env | xargs -d '\n')
  echo "Loaded $(wc -l /app/environment/.env) variables"

fi
java -jar $@

@oliver.marks I don't think I understood your question fully. For environment variables in CloudRun, I always think of two cases: 1. They are not secret and you know them at image build time - for these jib allows you to add the ENV metadata in the docker image (appending or overriding any environment variables from the base image) 2. In some ways, leaving them out of the image, and using the --set-env-vars switch when deploying a new version of the cloudrun service also feels right, and I think this over-rides anything that might have been baked into the image Are you trying to build this with a deps.edn project?

so I had them all stored in gcp secret manager, when you create a cloud run instance you can add env from secrets to a file which is what I hoped I could then use. In the end I added the env in the gui individually I was not aware of the --set-env-vars options on deply I guess thats if you use the cli in CI you can provide those ? oh and yeah its a deps.edn project

Oh hey! I didn't recognize it was you above. But ya, you can use --set-env-vars if yuou're deploying from glcoud for sure. Maybe we should put an :env map into jib.edn too? In your case, you might know that info at image build time.