Add support for Worker Deployment Versions (Go worker)#338
Merged
veeral-patel merged 4 commits intomainfrom Apr 24, 2026
Merged
Add support for Worker Deployment Versions (Go worker)#338veeral-patel merged 4 commits intomainfrom
veeral-patel merged 4 commits intomainfrom
Conversation
Adds --deployment-name and --default-versioning-behavior flags that wire the Go worker into Temporal's Worker Deployment Versioning via worker.DeploymentOptions. When --deployment-name is set, the worker registers as a versioned member of the deployment; otherwise the legacy --build-id path is preserved unchanged.
carlydf
reviewed
Apr 24, 2026
Makes the legacy and deployment paths independent: --build-id is the legacy Build-ID-based versioning input, and --deployment-build-id is the build identifier within a Worker Deployment. The two are mutually exclusive, and --deployment-build-id is required whenever --deployment-name is set.
Notes at the BuildID + UseBuildIDForVersioning call site that the Build-ID-based versioning API is deprecated and that new users should use --deployment-name + --deployment-build-id instead.
carlydf
approved these changes
Apr 24, 2026
| workerOpts := worker.Options{ | ||
| MaxConcurrentActivityExecutionSize: options.MaxConcurrentActivities, | ||
| MaxConcurrentWorkflowTaskExecutionSize: options.MaxConcurrentWorkflowTasks, | ||
| ActivityTaskPollerBehavior: makePollerBehavior( |
There was a problem hiding this comment.
nit: lack of aligned indents makes this harder to read imo (usually IDEs do the indent alignment, and AI-generated code does not, maybe it's "go fmt" not sure?)
Contributor
Author
There was a problem hiding this comment.
@carlydf I checked the files I modified in this PR with go fmt and they all passed the go fmt check!
THardy98
approved these changes
Apr 24, 2026
Contributor
THardy98
left a comment
THardy98
left a comment
There was a problem hiding this comment.
LGTM, couple nits worth addressing
| } | ||
| m.fs = pflag.NewFlagSet("worker_options", pflag.ExitOnError) | ||
| m.fs.StringVar(&m.BuildID, "build-id", "", "Build ID") | ||
| m.fs.StringVar(&m.BuildID, "build-id", "", "Build ID for legacy Build-ID-based worker versioning. Mutually exclusive with --deployment-name") |
Contributor
There was a problem hiding this comment.
might be worth explicitly marking this as deprecated (especially given that deployment-build-id exists)
Contributor
Author
There was a problem hiding this comment.
Done, I've updated the CLI arg description for build-id to mention it's deprecated.
| m.fs.StringVar(&m.BuildID, "build-id", "", "Build ID for legacy Build-ID-based worker versioning. Mutually exclusive with --deployment-name") | ||
| m.fs.StringVar(&m.DeploymentName, "deployment-name", "", "Worker Deployment name. When set, enables Worker Deployment Versioning and must be combined with --deployment-build-id") | ||
| m.fs.StringVar(&m.DeploymentBuildID, "deployment-build-id", "", "Build ID within the Worker Deployment. Required when --deployment-name is set") | ||
| m.fs.StringVar(&m.DefaultVersioningBehavior, "default-versioning-behavior", "", "Default versioning behavior for workflows that don't set one at registration. One of: pinned, auto-upgrade. Defaults to auto-upgrade when --deployment-name is set") |
Contributor
There was a problem hiding this comment.
do we want a default value here? (not sure if this is desirable, just a thought. Deferring to yall, feel free to ignore)
Contributor
Author
There was a problem hiding this comment.
@THardy98 No, I don't think there's a reasonable default we could set for the deployment name and build ID! But thank you for flagging!
veeral-patel
added a commit
to veeral-patel/keda
that referenced
this pull request
Apr 24, 2026
… worker Switch the deployment-version subtest from a locally-built temporal-deployment-worker image to a pinned tag of temporaliotest/omes that was built from the PR adding deployment versioning support to omes (temporalio/omes#338): docker.io/temporaliotest/omes:go-89ab7fe@sha256:791a2eecd942f78a207ce600a1c1c5d5800eb34167f6ec98c0722e91ea7d6771 This removes the need for a custom worker binary maintained in the KEDA tree, aligning the deployment-version test with the existing unversioned and build-id tests that already use omes. The image is public on Docker Hub so KEDA's CI cluster can pull it without any extra infrastructure. Also removes the now-unused tests/scalers/temporal/worker/ directory. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Veeral Patel <veeral.patel@temporal.io>
2 tasks
veeral-patel
added a commit
to veeral-patel/keda
that referenced
this pull request
Apr 29, 2026
… worker Switch the deployment-version subtest from a locally-built temporal-deployment-worker image to a pinned tag of temporaliotest/omes that was built from the PR adding deployment versioning support to omes (temporalio/omes#338): docker.io/temporaliotest/omes:go-89ab7fe@sha256:791a2eecd942f78a207ce600a1c1c5d5800eb34167f6ec98c0722e91ea7d6771 This removes the need for a custom worker binary maintained in the KEDA tree, aligning the deployment-version test with the existing unversioned and build-id tests that already use omes. The image is public on Docker Hub so KEDA's CI cluster can pull it without any extra infrastructure. Also removes the now-unused tests/scalers/temporal/worker/ directory. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com> Signed-off-by: Veeral Patel <veeral.patel@temporal.io>
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
3 participants
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.
Summary
This PR adds
--deployment-name,--deployment-build-id, and--default-versioning-behaviorflags to the Omes worker CLI.Context
Omes currently only supports the legacy Build ID based worker versioning scheme for the Go worker. This PR adds flags for Deployment Versions, and initializes the worker accordingly.
We continue to support the legacy Build ID based path, but I've added a comment stating that those flags are deprecated. We can phase out this path entirely in the near future.
Out of scope: Python / TypeScript / Java / .NET worker wiring
Files changed
cmd/clioptions/worker.goDeploymentName,DeploymentBuildID,DefaultVersioningBehaviorfields onWorkerOptionsand registered--deployment-name,--deployment-build-id,--default-versioning-behaviorflags. Clarified--build-iddescription as legacy and mutually exclusive with--deployment-name.workers/go/worker/worker.goworker.Optionsconstruction out of the per-task-queue goroutine. When--deployment-nameis set, buildsworker.DeploymentOptionsfromDeploymentName+DeploymentBuildID+ resolvedDefaultVersioningBehavior; otherwise keeps the legacyBuildID+UseBuildIDForVersioningpath (now commented as deprecated). AddedparseVersioningBehaviorhelper (acceptspinned,auto-upgrade; defaults toauto-upgradeon empty). Added up-front validation for the three mutually-exclusive / required-together flag combinations.Test plan
go build ./...passes"Started Worker" ... "BuildID": "v1"under--deployment-name omes-test --deployment-build-id v1 --default-versioning-behavior auto-upgrade--build-id+--deployment-name→ fatal--build-id and --deployment-name are mutually exclusive; use --deployment-build-id with --deployment-name--deployment-namewithout--deployment-build-id→ fatal--deployment-build-id is required when --deployment-name is set--deployment-build-idwithout--deployment-name→ fatal--deployment-build-id requires --deployment-name--default-versioning-behavior bogus→ fatalinvalid --default-versioning-behavior "bogus" (expected pinned or auto-upgrade)--build-idpath compiles and reaches the deprecated code branch (runtime end-to-end depends on task-queue Build-ID assignment rules, unchanged from prior behavior)