feat: passthrough extra args for adk deploy cloud_run as Cloud Run args

[jackwotherspoon]

The command adk deploy cloud_run supports limited gcloud run deploy args 😢.

Which makes the command fine for simple deployments...

It should support all current and future Cloud Run deployment args for the command to be widely adopted.

This can easily be done by passing through all extra args passed to adk deploy cloud_run to gcloud...

This PR assumes any extra args/flags passed after AGENT_PATH are gcloud flags.

Example

# ADK flags
adk deploy cloud_run \
--project=$GOOGLE_CLOUD_PROJECT \
--region=$GOOGLE_CLOUD_LOCATION \
$AGENT_PATH \
# NEW gcloud run deploy flags
--min-instances=2 \
--no-allow-unauthenticated

This gives full Cloud Run feature support to ADK users 🤖 🚀

Test Plan

To test you can just build locally or pip install feature branch directly:

uv venv
uv pip install git+https://github.com/jackwotherspoon/adk-python.git

Deploy to Cloud Run using additional arguments following AGENT_PATH, such as --min-instance=2 or --description="Cloud Run test":

uv run adk deploy cloud_run \
--project=$GOOGLE_CLOUD_PROJECT \
--region=$GOOGLE_CLOUD_LOCATION \
--with_ui \
$AGENT_PATH \
--labels=test-label=adk \
--min-instances=2

You can click on the Cloud Run service after deployment and check the service yaml, you should see the additional label etc.

Fixes #2351

[adk-bot]

Response from ADK Triaging Agent

Hello @jackwotherspoon, thank you for creating this PR!

To help us review this PR, could you please address the following from our contribution guidelines:

• Single Commit: Please squash the multiple commits into a single commit.
• Testing Plan: Please include a testing plan section in your PR description to detail how you've tested these changes.

You can find more details in our contribution guidelines.

This information will help reviewers to review your PR more efficiently. Thanks!

[hangfei]

Please add testing plan(log or screenshot)

[adk-bot]

Response from ADK Triaging Agent

Hello @jackwotherspoon, thank you for updating the PR with a testing plan!

Before this can be reviewed, could you please address the following:

• CI Checks: The pyink-check and test (3.9) checks are failing. Please fix these issues so all checks are passing.
• Single Commit: As mentioned previously, please squash the multiple commits into a single one.

You can find more details in our contribution guidelines.

These changes are needed before the reviewers can proceed. Thank you!

[hangfei]

where is adk-labels? could you assert that?

[hangfei]

what if extra arg conflicts with existing args? raise error(other than the labels)?

[Jacksunwei]

@jackwotherspoon I see there is a merge conflict, could you help resolve?

[Jacksunwei]

This would make it harder to maintain long-term.

I'd recommend adding a --gcloud_extra_arg option (with --multiple=True) to host.

Usage pattern could be --gcloud_extra_arg="--args1=val1" --gcloud_extra_arg="--args2=val2"

[jackwotherspoon]

This would make it harder to maintain long-term.

@Jacksunwei can you explain why this makes it harder to maintain...?

Seems way easier to maintain than the current approach of adding supported flags one by one.

[jackwotherspoon]

Usage pattern could be --gcloud_extra_arg="--args1=val1" --gcloud_extra_arg="--args2=val2"

From a DevX perspective I find this much worse than my current approach (in my opinion), you are asking folks to learn something new and have to do extra work to convert...

Versus telling folks to "take any of your existing Cloud Run deployments and copy your flags and just append them to your command".

The second option feels a bit more magical and it "just works"

[Jacksunwei]

I think it makes things confusing. From user's perspective, when they do adk deploy cloud_run --arg1 val1 --arg2 val2.

There is no easy way to tell whether arg1 is for adk deploy cloud_run or for the underlying gcloud command.

User cannot have help text from adk deploy cloud_run --help, either.

It appears to be doing less things, but it will just confuse people and shut our door to provide any additional options in the future, because if gcloud also has an option of the same name, we may accidentally break users' existing setup.

[jackwotherspoon]

@Jacksunwei I think you may be mis-understanding...

Anything after AGENT_PATH is considered a gcloud arg, everything before is ADK flag...

# ADK flags
adk deploy cloud_run \
--project=$GOOGLE_CLOUD_PROJECT \
--region=$GOOGLE_CLOUD_LOCATION \
$AGENT_PATH \
# NEW gcloud run deploy flags
--min-instances=2 \
--no-allow-unauthenticated

There is no easy way to tell whether arg1 is for adk deploy cloud_run or for the underlying gcloud command.

Yes there is, anything before AGENT_PATH is an ADK arg, if I try and add a gcloud flag before AGENT_PATH it will error:

Try 'adk deploy cloud_run --help' for help.

Error: No such option: --allow-unauthenticated

User cannot have help text from adk deploy cloud_run --help, either.

Yes they can, adk deploy cloud_run --help, works fine. Only time it would potentially not work is --help after the AGENT_PATH.

because if gcloud also has an option of the same name, we may accidentally break users' existing setup.

This is a fair point, but do we really see this being the case...? Is there a plan to add a bunch more flags to adk deploy cloud_run? The benefits here seem to be huge.