feat(gcp): add Cloud Run service and job resources

[Amit2465]

Description

Add GCP Cloud Run service (cloud-run-service) and Cloud Run job (cloud-run-job) as new supported cloud-nuke resources.

How it works

List: Enumerates all available Cloud Run locations for the project using the Cloud Run Admin API v1 REST client, then queries each location individually using the v2 gRPC client. The v2 API does not support the locations/- wildcard for ListServices or ListJobs, so explicit location enumeration is required. Both resources share a common listCloudRunLocations helper. If listing fails for a given location, that location is skipped without aborting the remaining locations.

Delete: Sends a delete request for each resource using the v2 gRPC client and waits for the returned long-running operation to complete. Already-deleted resources (404) are handled gracefully. For jobs, any active executions are automatically cancelled by the API before deletion.

Identifier format: Full resource name — projects/{project}/locations/{location}/services/{name} and projects/{project}/locations/{location}/jobs/{name}

Test output

=== RUN   TestCloudRunServices_ResourceName
--- PASS: TestCloudRunServices_ResourceName (0.00s)
=== RUN   TestCloudRunServices_MaxBatchSize
--- PASS: TestCloudRunServices_MaxBatchSize (0.00s)
=== RUN   TestCloudRunJobs_ResourceName
--- PASS: TestCloudRunJobs_ResourceName (0.00s)
=== RUN   TestCloudRunJobs_MaxBatchSize
--- PASS: TestCloudRunJobs_MaxBatchSize (0.00s)
PASS
ok  	github.com/gruntwork-io/cloud-nuke/gcp/resources	0.021s

Pre-commit checks:

• gofmt — no issues
• golangci-lint run ./... — 0 issues
• go build ./... — clean
• go vet ./... — clean

Manually verified against a real GCP project:

• inspect-gcp correctly lists both Cloud Run services and jobs
• Deletion completes successfully with LRO polling for both resource types

TODOs

Read the Gruntwork contribution guidelines.

• Update the docs.
• Run the relevant tests successfully, including pre-commit checks.
• Ensure any 3rd party code adheres with our license policy or delete this line if its not applicable.
• Include release notes. If this PR is backward incompatible, include a migration guide.
• Attention Grunts - if this PR adds support for a new resource, ensure the nuke_sandbox and nuke_phxdevops jobs in .circleci/config.yml have been updated with appropriate exclusions. (Note: nuke_sandbox and nuke_phxdevops only run aws, so no exclusions are needed for these new GCP resources.)

Release Notes (draft)

Added GCP Cloud Run service (cloud-run-service) and Cloud Run job (cloud-run-job) as new supported resource types.

Migration Guide

This PR introduces cloud-run-service and cloud-run-job as new GCP resource types. Since cloud-nuke automatically includes all registered resource types, Cloud Run services and jobs will be nuked by default if no config file is provided.
To opt out, add the following to your cloud-nuke.yml config file:

GcpCloudRunService:
  exclude:
    names_regex:
      - ".*"

GcpCloudRunJob:
  exclude:
    names_regex:
      - ".*"

[james00012]

Good structure — clean split between shared location enumeration (v1) and resource-specific list/delete (v2 gRPC). A few items:

1. listCloudRunLocations creates a new v1 client on every call — Both listCloudRunServices and listCloudRunJobs call this, so each nuke run creates two throwaway v1 REST clients. Consider creating it once or
   caching the location list.
2. Services should be deleted before jobs — If a Cloud Run job is triggered by a Cloud Run service (e.g. via Cloud Scheduler or a service invoking a job), deletion order could matter. Currently both are
   registered independently in getRegisteredGlobalResources() with no ordering guarantee. Is that safe?
3. Location errors are silently skipped during listing — If a real API error occurs (e.g. auth failure), it's logged at Debug level and the location is skipped. Consider distinguishing between "Cloud Run not
   enabled in this location" (expected) and actual errors (unexpected).
4. Missing t.Parallel() in all four test functions across both test files.
5. Minimal test coverage — Tests only check ResourceName() and MaxBatchSize(). The location enumeration, multi-region listing, label filtering, and NotFound handling in delete are all untested.
6. Global registration for regional resources — Same pattern as the other GCP resources, but Cloud Run services and jobs are regional. Worth confirming this is intentional.