Skip to content

Add Google Cloud Run worker-identity sample - #356

Draft
seanbollin wants to merge 6 commits into
mainfrom
cloud-run-worker-id
Draft

Add Google Cloud Run worker-identity sample#356
seanbollin wants to merge 6 commits into
mainfrom
cloud-run-worker-id

Conversation

@seanbollin

@seanbollin seanbollin commented Aug 25, 2026

Copy link
Copy Markdown

What

Runnable Google Cloud Run worker-identity sample, laid out under gcp/cloud_run/worker_id/ to match the sibling OpenTelemetry Cloud Run sample (gcp/cloud_run/opentelemetry/). It registers WorkerIDPlugin() on the client so the worker identity ({instanceId}@{revision}) is set from Cloud Run instance metadata; a greeting Workflow/Activity and a starter demonstrate a normal long-lived Worker on a Cloud Run worker pool. No Worker Deployment Versioning — identity only.

  • worker.py — registers WorkerIDPlugin(), runs a long-lived Worker until Cloud Run sends SIGTERM, and logs the identity via get_google_cloud_run_metadata().worker_identity.
  • workflows.py / activities.py — a small greeting Workflow + Activity.
  • settings.py — reads TEMPORAL_ADDRESS / TEMPORAL_NAMESPACE / TEMPORAL_TASK_QUEUE (plaintext), with optional TEMPORAL_API_KEY for Temporal Cloud (TLS).
  • starter.py — starts the Workflow from a local machine.
  • Dockerfile / .dockerignore — container build for gcloud run worker-pools deploy.
  • README.md — explains Cloud Run worker pools and the deploy flow.

The gcp/__init__.py and gcp/cloud_run/__init__.py namespace packages are byte-identical to the OpenTelemetry sample's so the two samples merge cleanly, and tests/gcp/cloud_run/worker_id/ mirrors the OTel test layout.

Run

See gcp/cloud_run/worker_id/README.md for the full gcloud run worker-pools deploy flow; start a Workflow locally from the repo root with uv run python -m gcp.cloud_run.worker_id.starter.

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-referenced temporalio (documented in the Dockerfile).

Verification

  • ruff check and ruff format --check pass on the sample; mypy is clean.
  • Sample modules import cleanly against a local SDK build that includes the helper (WorkerIDPlugin, get_google_cloud_run_metadata).
  • python -m py_compile passes, and tests/gcp/cloud_run/worker_id/workflow_test.py is collected by pytest.

🤖 Generated with Claude Code

seanbollin and others added 6 commits August 25, 2026 13:49
Add a runnable sample that runs a long-lived Temporal Worker in a Google Cloud
Run worker pool and uses temporalio.contrib.gcp.cloud_run to derive the worker
identity and a PINNED Worker Deployment version from Cloud Run instance
metadata. The sample registers a small greeting Workflow and Activity, reads
TEMPORAL_ADDRESS / TEMPORAL_NAMESPACE / TEMPORAL_TASK_QUEUE (plaintext or, with
TEMPORAL_API_KEY, Temporal Cloud over TLS), and runs until Cloud Run sends
SIGTERM.

The sample is standalone and excluded from the root project's build/lint/type
tooling, mirroring the lambda_worker sample.

The Cloud Run metadata helper is not released yet, so pyproject.toml pins
temporalio to the local SDK checkout (../../sdk-python-2) on the
cloud-run-worker-id branch; the README and Dockerfile note this must be dropped
for a released (or git-pinned) temporalio once the helper ships.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Register temporalio.contrib.gcp.cloud_run.CloudRunPlugin on the client
via Client.connect(plugins=[...]) instead of manually fetching metadata
and passing identity= and deployment_config=. The plugin sets the client
identity and the PINNED worker deployment config from Cloud Run instance
metadata and propagates to the worker automatically.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The SDK renamed the generic CloudRunPlugin to WorkerIDPlugin (Cloud Run
can host multiple plugins). Update the sample's worker, README, and the
pyproject comment to match the new class name.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The plugin moved from temporalio.contrib.gcp.cloud_run into the
temporalio.contrib.gcp.cloud_run.worker_id sub-package (to avoid a
collision with the OTel Cloud Run plugin). Update the sample's import,
docstring, README doc link, and pyproject comment to the new path:

    from temporalio.contrib.gcp.cloud_run.worker_id import WorkerIDPlugin

The public name WorkerIDPlugin is unchanged.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
…ub versioning

Move gcp_cloud_run_worker_id/* into gcp/cloud_run/worker_id/ to mirror the
sibling OpenTelemetry Cloud Run sample layout, add the gcp / gcp.cloud_run /
gcp.cloud_run.worker_id namespace packages (the two parents byte-identical to
the OTel sample's), and mirror the tests/gcp/cloud_run/worker_id/ structure.

WorkerIDPlugin is now identity-only, so remove every Worker Deployment
Versioning reference (deployment name/config, build id, PINNED, versioning
behavior) from the sample. It now registers WorkerIDPlugin() and shows the
worker identity via get_google_cloud_run_metadata().worker_identity. Switch the
sample to package-qualified imports and run the worker/starter as modules
(python -m ...), matching the OTel sample's Dockerfile, and stop excluding the
sample from ruff/mypy/setuptools now that it lives in the gcp package tree.

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants