Why does adkgo deploy cloudrun need Secret Manager Secret Accessor role?

[ejstembler]

I'm trying to deploy to cloud run, using this bash script:

#!/usr/bin/env bash
set -euo pipefail

gcloud auth activate-service-account --key-file=$GOOGLE_APPLICATION_CREDENTIALS

adkgo deploy cloudrun \
    -p $GOOGLE_CLOUD_PROJECT \
    -r $CLOUD_RUN_REGION \
    -s $CLOUD_RUN_SERVICE_NAME \
    --proxy_port=8081 \
    --server_port=8080 \
    -e "./cmd/my-agent/main.go" \
    --a2a --api --webui

Getting this error output:

> Uploading sources..........................done
          > Building Container...................................................................................................................................................................................................done
          > Creating Revision....................................failed
          > Deployment failed
          > ERROR: (gcloud.run.deploy) spec.template.spec.containers[0].env[0].value_from.secret_key_ref.name: Permission denied on secret: projects/nnnn/secrets/GOOGLE_API_KEY/versions/latest for Revision service account nnnn-compute@developer.gserviceaccount.com. The service account used must be granted the 'Secret Manager Secret Accessor' role (roles/secretmanager.secretAccessor) at the secret, project or higher level.
          > 
Deploying to Cloud Run : Finished with error
Error: exit status 1

Why is it trying to use the default compute account? And why does it need GOOGLE_API_KEY defined in Secret Manager?

I do regular deployments to Cloud Run all the time and none of my deployments require Secret Manager. ENVs defined in CI/CD and Docker images. It works just fine.

[ejstembler]

The related issue is why doesn't adkgo deploy cloudrun support a --service-account= flag?

[ejstembler]

After perusing the source, and the generated Dockerfile:

FROM gcr.io/distroless/static-debian11

COPY main  /app/main
EXPOSE 8080
# Command to run the executable when the container starts
CMD ["/app/main", "web", "-port", "8080", "api", "-webui_address", "127.0.0.1:8081", "a2a", "--a2a_agent_url", "http://127.0.0.1:8081", "webui", "--api_server_address", "http://127.0.0.1:8081/api"]

I can just forgo using adkgo deploy cloudrun and resort to my previous cloud run deploys...

[aniruddhaadak80]

The confusing part here is that there are really two separate questions hidden in one deploy failure. One is why the generated deployment binds to the default compute service account, and the other is why the deployment path assumes GOOGLE_API_KEY should come from Secret Manager instead of plain env injection.nnIf adkgo deploy is opinionated about Secret Manager, that should be explicit and ideally configurable with flags for service account and secret behavior. Otherwise people who already have a working Cloud Run pipeline will hit exactly this kind of surprise because the helper command is making infrastructure choices on their behalf.