deploy.cloudrun: sandboxLauncher field is silently dropped (missing in the pinned google.golang.org/api Container struct)

[clouddev-code]

Title

deploy.cloudrun: sandboxLauncher field is silently dropped (missing in the pinned google.golang.org/api Container struct)

Body

Expected behavior

Deploying a Cloud Run service manifest with sandboxLauncher: true set on a container via skaffold deploy (or via Cloud Deploy, which uses skaffold's deploy.cloudrun deployer internally) should result in a revision that actually has Cloud Run Sandboxes enabled for that container.

Actual behavior

The field is silently ignored — no error, no warning. The resulting revision never has the sandbox launcher enabled, even though the manifest explicitly sets it. This is only detectable by inspecting the deployed revision afterwards (e.g. gcloud run revisions describe ... --format=export) and noticing sandboxLauncher is missing.

Root cause (identified by reading the vendored source)

pkg/skaffold/deploy/cloudrun/deploy.go unmarshals the rendered YAML manifest into the Container struct from google.golang.org/api/run/v1 before sending it to the Cloud Run Admin API. The version of google.golang.org/api that skaffold currently pins (v0.283.0 at the time of testing) does not define a SandboxLauncher field on that Container struct. Because Go's JSON/YAML unmarshaling silently drops unknown fields by default, sandboxLauncher: true in the source manifest is dropped with no error or warning anywhere in the skaffold or Cloud Deploy logs.

By contrast, gcloud beta run deploy --sandbox-launcher and a direct gcloud run services replace (or the Cloud Run Admin API directly) do apply the field correctly — confirming the field name/location is correct and the gap is specifically in skaffold's vendored client library version, not in the manifest itself.

Why this is worse for Cloud Deploy users specifically

Via Cloud Deploy, this is not just a "the field isn't supported yet" gap — it's effectively unfixable from the user's side. Cloud Deploy pins a fixed, Google-managed skaffold version per release track (defaultSkaffoldVersion, see gcloud deploy get-config) that cannot be overridden or upgraded by the user. So even after registering the fact that some newer google.golang.org/api release does model this field, a Cloud Deploy user has no way to pick it up until Google bumps the pinned skaffold engine version. Standalone skaffold CLI users at least have the option to build a newer skaffold themselves.

The only workaround we found was to bypass the built-in run: target type entirely and use a Cloud Deploy Custom Target Type that shells out to gcloud run services replace directly.

Steps to reproduce

1. Author a Cloud Run service manifest with a container that sets sandboxLauncher: true.
2. Deploy it with skaffold deploy using the cloudrun deploy type (or via Cloud Deploy using the built-in run: target, which uses the same deployer).
3. Inspect the resulting revision: gcloud run revisions describe <revision> --format=export.
4. Observe that sandboxLauncher is absent from the exported spec, and that the sandbox launcher binary (/usr/local/gcp/bin/sandbox) is not present in the running container.

Environment

• Deploy path: Cloud Deploy managed cd-skaffold engine (pinned skaffold version, not user-selectable)
• google.golang.org/api version observed in the vendored dependency tree: v0.283.0
• Confirmed correct behavior as a baseline via gcloud beta run deploy --sandbox-launcher and gcloud run services replace on the same project/service

Suggested fix

Bump the vendored google.golang.org/api dependency to a version that models SandboxLauncher on the Cloud Run v1 Container struct (if such a version exists), or forward the field through even if the client library doesn't model it explicitly (e.g. read/round-trip it via a raw map so unknown-but-valid API fields aren't silently dropped).

Related

hashicorp/terraform-provider-google#28426 reports the same underlying gap (missing sandboxLauncher support) for google_cloud_run_v2_service/google_cloud_run_service, which points at the same class of problem in the Cloud Run Go client tooling ecosystem, though that issue is scoped to the Terraform provider rather than skaffold.

Happy to provide more detail on the manifest/setup used for reproduction if useful.