Add Cloud Run worker-ID sample - #531
Draft
seanbollin wants to merge 3 commits into
Draft
Conversation
Mirror the lambda-worker sample for Google Cloud Run: a long-running worker that uses the go.temporal.io/sdk/contrib/gcp/cloudrun helper to derive its identity (<instanceID>@<revision>) and Worker Deployment Version (name + revision) from the Cloud Run instance metadata at startup, pinning workflows to that version by default. It reads TEMPORAL_ADDRESS/TEMPORAL_NAMESPACE/TEMPORAL_TASK_QUEUE (plaintext), registers a greeting workflow + activity, and stops gracefully on SIGTERM. The README explains Cloud Run worker pools and deployment via `gcloud run worker-pools deploy`. The cloudrun contrib module is unreleased, so go.mod carries a TEMPORARY local replace to ../sdk-go-2/contrib/gcp/cloudrun (the helper compiles against the released SDK, so no SDK replace is needed; the new dependency does raise the module go directive to 1.26). The replace must be dropped once the module is released, hence this PR is a draft. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Update the Cloud Run worker sample to register cloudrun.Plugin on the client instead of calling the removed Metadata.ApplyToClientOptions/ApplyToWorkerOptions methods. The plugin fetches the instance metadata at connect time, sets the worker identity, and pins the worker's deployment version; the sample reads the resolved metadata back via plugin.Metadata() for logging. Bump go.temporal.io/api to v1.63.5 (go mod tidy) as required by the updated contrib/gcp/cloudrun module. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The Cloud Run worker-ID plugin moved from module go.temporal.io/sdk/contrib/gcp/cloudrun to go.temporal.io/sdk/contrib/gcp/cloudrun/workerid (Go package cloudrun -> workerid) so the cloudrun directory can also host the OpenTelemetry plugin without a package collision. Follow that here: - import go.temporal.io/sdk/contrib/gcp/cloudrun/workerid and use workerid.NewPlugin / workerid.PluginOptions in worker/main.go - point the go.mod require and local replace at the new module path - update the README and Dockerfile references go build and go vet pass against the in-repo module. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
What
Adds a Cloud Run worker-ID sample (
cloud-run-worker-id/) that mirrors the existinglambda-worker/sample. It runs a long-running Temporal worker on Google Cloud Run and uses the newgo.temporal.io/sdk/contrib/gcp/cloudrunhelper toderive, from the Cloud Run instance metadata at startup:
<instanceID>@<revision>(with@<name>/ bare-<instanceID>fallbacks), and(deploymentName=name, buildID=revision), with a PINNEDdefault versioning behavior.
It reads
TEMPORAL_ADDRESS/TEMPORAL_NAMESPACE/TEMPORAL_TASK_QUEUE(plaintext connection),registers a small greeting workflow + activity, and shuts down gracefully on
SIGTERM. The READMEexplains Cloud Run worker pools and deployment via
gcloud run worker-pools deploy.Files
cloud-run-worker-id/worker/main.go— the worker (FetchMetadata → ApplyToClientOptions / ApplyToWorkerOptions)cloud-run-worker-id/starter/main.go— starts a workflow against itcloud-run-worker-id/greeting/{workflow,activity}.go— sample workflow + activitycloud-run-worker-id/{Dockerfile,README.md}Draft: temporary dependency wiring
The
cloudruncontrib module is unreleased (see sdk-go #2599), sogo.modcarries a temporarylocal replace:
go.temporal.io/sdk(v1.48.0), so nogo.temporal.io/sdkreplace is needed and
go.sumis unchanged. Adding the dependency does raise the module'sgodirective to
1.26(the contrib module targets Go 1.26).--sourcebuild cannot reach the sibling../sdk-go-2, so theDockerfile/ deploy buildonly work once the module is published and the replace is removed.
This PR must stay a draft until the
cloudrunmodule is released, at which point the replace isdropped and the require switched to the released version.
Verified locally:
go build,go vet, andgofmt -lare clean for./cloud-run-worker-id/....Note for reviewers: overlap with the OpenTelemetry Cloud Run sample
There is a separate, parallel effort on branch
gcp-cloud-run-otelthat adds acloud-run-worker/sample demonstrating the
cloudrunOpenTelemetry plugin. This PR is a different sample(worker identity + deployment versioning) and deliberately uses a distinct directory name
(
cloud-run-worker-id/) to avoid collision. If both land, we may want to reconcile naming or fold thetwo into one Cloud Run sample directory.
🤖 Generated with Claude Code