Add Google Cloud Run worker-identity sample

[seanbollin]

What

Adds a runnable Google Cloud Run worker pool sample under gcp_cloud_run_worker_id/ that uses the new temporalio.contrib.gcp.cloud_run helper to derive a worker identity (<instance_id>@<revision>) and a PINNED Worker Deployment version from Cloud Run instance metadata, then runs a long-lived Worker until Cloud Run sends SIGTERM.

• worker.py — derives identity + worker_deployment_config from get_google_cloud_run_metadata() and runs a versioned Worker.
• workflows.py / activities.py — a small greeting Workflow (PINNED versioning behavior) + Activity.
• settings.py — reads TEMPORAL_ADDRESS / TEMPORAL_NAMESPACE / TEMPORAL_TASK_QUEUE (plaintext), with optional TEMPORAL_API_KEY for Temporal Cloud (TLS).
• starter.py — starts a Workflow from a local machine.
• Dockerfile / .dockerignore — container build for gcloud run worker-pools deploy.
• README.md — explains Cloud Run worker pools and the gcloud run worker-pools deploy … --set-env-vars … flow.

Structure mirrors the existing lambda_worker sample (standalone directory, own pyproject.toml, excluded from the root project's build/lint/type tooling).

Draft — depends on an unreleased helper

The Cloud Run metadata helper is not released yet (SDK PR: temporalio/sdk-python#1776). To keep this sample runnable, pyproject.toml pins temporalio to a local path source (../../sdk-python-2) on the cloud-run-worker-id branch. This [tool.uv.sources] override must be dropped (in favor of a released temporalio) once the helper ships; the README and Dockerfile call this out. The local path is not available inside a Docker build context, so the container build must use a released or git-pinned temporalio (documented in the Dockerfile).

Note: directory naming vs. the Cloud Run OpenTelemetry sample

There is a separate in-flight Cloud Run effort that adds a gcp_cloud_run/ sample (OpenTelemetry plugin). To avoid a directory collision, this worker-identity sample is named gcp_cloud_run_worker_id/. If both land, we may want to consolidate them under a single gcp_cloud_run/ sample (worker identity + OTel) or settle on a consistent naming scheme — flagging here for a maintainer decision before un-drafting.

Verification

• Sample modules import cleanly against a local SDK build that includes the helper.
• ruff check --select I (isort) and ruff format --check pass on the sample.
• The helper itself is covered by unit tests in Add Google Cloud Run worker identity/deployment helper sdk-python#1776.

🤖 Generated with Claude Code