Add port for the Frontend service. - #123
Merged
Merged
Conversation
|
|
feedmeapples
approved these changes
Feb 21, 2023
chaptersix
added a commit
that referenced
this pull request
Jun 4, 2026
## Related issues <!-- Closes #123 --> Closes #609 ## What changed? <!-- Describe what this PR does at a high level. --> Prefix generated dev server cluster IDs with `dev-server-` for better identification. Previously cluster IDs were plain UUIDs with no indication they came from a dev server. ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [x] Breaking changes are marked with 💥 in the PR title and release notes **Design** - [x] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) **Tests** - [x] Added functional test(s) — existing tests cover this change ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless ``` **Happy path** ``` $ temporal operator cluster describe ClusterId dev-server-<uuid> ``` **Error case** N/A Co-authored-by: Alex Stanfield <13949480+chaptersix@users.noreply.github.com>
Shivs11
added a commit
that referenced
this pull request
Jul 6, 2026
## Related issues <!-- Closes #123 --> ## What changed? - WISOTT - For more information, you can also view the relevant PR's: 1. Server PR: temporalio/temporal#10763 2. API PR: temporalio/api#808 ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [x] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [x] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [x] New flags don't duplicate an existing flag that serves the same purpose - [x] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [x] Results go to stdout; errors and warnings go to stderr - [x] Error messages are lowercase with no trailing punctuation **Tests** - [x] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests **Setup** Requires a server that includes temporalio/temporal#10763 and a workflow whose Task Queue is present in the target Worker Deployment Version. ```bash temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` Use an existing Worker Deployment Version for the target: ```text Deployment name: YourDeploymentName Build ID: YourBuildId ``` **Happy path** ```bash temporal workflow update-options \ --workflow-id YourWorkflowId \ --versioning-override-behavior one_time \ --versioning-override-deployment-name YourDeploymentName \ --versioning-override-build-id YourBuildId ``` Expected output: ```text Update workflow options succeeded ``` Verify table output: ```bash temporal workflow describe \ --workflow-id YourWorkflowId ``` Expected: `OverrideBehavior` is `OneTime`, with `OverrideTargetVersionDeploymentName` and `OverrideTargetVersionBuildId` set. Verify JSON output: ```bash temporal workflow describe \ --workflow-id YourWorkflowId \ --output json ``` Expected: `versioningInfo.versioningOverride.oneTime.targetDeploymentVersion` contains the deployment name and build ID. **Error case** ```bash temporal workflow update-options \ --workflow-id YourWorkflowId \ --versioning-override-behavior one_time ``` Expected: ```text Error: missing deployment name and/or build id with 'one_time' behavior ``` ```bash echo $? ``` Expected: ```text 1 ``` **Composition** ```bash temporal workflow update-options \ --query 'WorkflowId = "YourWorkflowId"' \ --yes \ --versioning-override-behavior one_time \ --versioning-override-deployment-name YourDeploymentName \ --versioning-override-build-id YourBuildId ``` Expected: a batch update-options job is started. Use `temporal batch describe` to inspect the batch, then `temporal workflow describe` on an affected Workflow Execution to verify the one-time override.
chaptersix
pushed a commit
that referenced
this pull request
Jul 6, 2026
## Related issues <!-- Closes #123 --> ## What changed? Bump ui-server to v2.50.1 for News Feed feature <!-- Describe what this PR does at a high level. -->
chaptersix
pushed a commit
that referenced
this pull request
Jul 9, 2026
## Related issues <!-- Closes #123 --> ## What changed? Bump UI server v2.52.0 ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable
chaptersix
pushed a commit
that referenced
this pull request
Jul 10, 2026
Use the proper name for the SA NexusEndpoint -> Endpoint. ## Related issues <!-- Closes #123 --> ## What changed? Fix the description for list. ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` **Happy path** ``` $ temporal <command> \ --flag value <expected output> ``` **Error case** ``` $ temporal <command> \ --invalid-combination Error: <expected error message> $ echo $? 1 ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` $ temporal <command-one> ... $ temporal <command-two> --flag <value-from-above> <expected output> ```
chaptersix
pushed a commit
that referenced
this pull request
Jul 20, 2026
…nd (#1103) Mirror the AWS Lambda support: four `--gcp-cloud-run-*` flags on `create-version` and `update-version-compute-config`, writing a gcp-cloud-run ComputeConfig provider. ## Related issues <!-- Closes #123 --> ## What changed? ### Add GCP Cloud Run worker pools as a compute provider Lets an operator point a Worker Deployment Version at a GCP Cloud Run worker pool, mirroring the existing AWS Lambda support 1:1. CLI-only — serializes the four detail keys WCI reads (`project`, `region`, `worker_pool`, `service_account`) ``` temporal worker deployment create-version \ --deployment-name YourDeployment --build-id YourBuildID \ --gcp-cloud-run-project YourProject \ --gcp-cloud-run-region us-central1 \ --gcp-cloud-run-worker-pool YourWorkerPool \ --gcp-cloud-run-service-account customer-sa@proj.iam.gserviceaccount.com ``` ### Changes - **commands.yaml / commands.gen.go**: four `--gcp-cloud-run-*` flags on `create-version` and `update-version-compute-config`, plus usage examples. - **commands.worker.deployment.go**: GCP validate/payload helpers and a shared `computeProviderConfig` selector that enforces AWS/GCP mutual exclusivity and dispatches on the trigger flag. Both `run` methods rewired. - **tests**: GCP validation + mutual-exclusivity cases folded into `TestCreateWorkerDeploymentVersion_Errors`; a skipped round-trip test mirrors the Lambda one (needs real GCP fixtures). ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [x] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [x] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [x] New flags don't duplicate an existing flag that serves the same purpose - [x] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [x] Summaries use sentence case and have no trailing period - [x] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [x] Results go to stdout; errors and warnings go to stderr - [x] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [x] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` ./temporal --profile "ns-cloud-run-test" worker deployment create-version \ --deployment-name "cloud-run-deployment" \ --build-id "1.0" \ --gcp-cloud-run-project "compute-team-sandbox" \ --gcp-cloud-run-region "us-west1" \ --gcp-cloud-run-worker-pool "omes-worker-pool" \ --gcp-cloud-run-service-account "wci-invocation-sa@compute-team-sandbox.iam.gserviceaccount.com" Successfully created worker deployment version ``` **Happy path** ``` ./temporal --profile "ns-cloud-run-test" worker deployment describe-version \ --deployment-name "cloud-run-deployment" \ --build-id "1.0" Worker Deployment Version: DeploymentName cloud-run-deployment BuildID 1.0 CreateTime 2 minutes ago RoutingChangedTime a long while ago CurrentSinceTime a long while ago RampingSinceTime a long while ago RampPercentage 0 ComputeConfigSummary gcp-cloud-run ``` **Error case** ``` ./temporal --profile "ns-cloud-run-test" worker deployment create-version \ --deployment-name "cloud-run-deployment" \ --build-id "1.0" \ --gcp-cloud-run-project "compute-team-sandbox" \ --gcp-cloud-run-region "us-west1" \ --gcp-cloud-run-worker-pool "fake-omes-worker-pool" \ --gcp-cloud-run-service-account "wci-invocation-sa@compute-team-sandbox.iam.gserviceaccount.com" Error: error creating worker deployment version: Worker Deployment Version "cloud-run-deployment.1.0" already exists ./temporal --profile "ns-cloud-run-test" worker deployment create-version \ --deployment-name "cloud-run-deployment" \ --build-id "2.0" \ --gcp-cloud-run-project "compute-team-sandbox" \ --gcp-cloud-run-region "us-west1" \ --gcp-cloud-run-worker-pool "fake-omes-worker-pool" \ --gcp-cloud-run-service-account "wci-invocation-sa@compute-team-sandbox.iam.gserviceaccount.com" Error: error creating worker deployment version: default: worker pool "projects/compute-team-sandbox/locations/us-west1/workerPools/fake-omes-worker-pool" not found: rpc error: code = NotFound desc = Resource 'fake-omes-worker-pool' of kind 'WORKER_POOL' in region 'us-west1' in project 'compute-team-sandbox' does not exist. ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` $ temporal <command-one> ... $ temporal <command-two> --flag <value-from-above> <expected output> ```
pull Bot
pushed a commit
to amit-writes-code/cli
that referenced
this pull request
Aug 5, 2026
## Related issues <!-- Closes temporalio#123 --> ## What changed? <!-- Describe what this PR does at a high level. --> Bump UI server v2.53.1 ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` **Happy path** ``` $ temporal <command> \ --flag value <expected output> ``` **Error case** ``` $ temporal <command> \ --invalid-combination Error: <expected error message> $ echo $? 1 ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` $ temporal <command-one> ... $ temporal <command-two> --flag <value-from-above> <expected output> ```
pull Bot
pushed a commit
to amit-writes-code/cli
that referenced
this pull request
Aug 7, 2026
## Related issues <!-- Closes temporalio#123 --> ## What changed? Render links on activity describe- temporalio#1131 <!-- Describe what this PR does at a high level. --> ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [x] Breaking changes are marked with 💥 in the PR title and release notes - [x] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [x] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable Before: ``` $ temporal nexus operation describe --operation-id op-1 OperationId op-1 RunId run-1 Endpoint payments Service PaymentService Operation charge Status Running State Started Attempt 1 ``` After: ``` $ temporal nexus operation describe --operation-id op-1 OperationId op-1 RunId run-1 Endpoint payments Service PaymentService Operation charge Status Running State Started Attempt 1 Links: 1 temporal:///namespaces/default/workflows/payment-workflow/run-1/history?eventID=12&eventType=NexusOperationScheduled&referenceType=EventReference ``` Before: ``` $ temporal activity describe --activity-id act-1 Activity Execution Info: ActivityId act-1 RunId run-1 Type MyActivity Status Running TaskQueue tq Attempt 1 StateTransitionCount 0 Callbacks: STATE ATTEMPT Succeeded 2 ``` After: ``` $ temporal activity describe --activity-id act-1 Activity Execution Info: ActivityId act-1 RunId run-1 Type MyActivity Status Running TaskQueue tq Attempt 1 StateTransitionCount 0 Callbacks: 1 URL http://callback.example/cb Links [temporal:///namespaces/default/workflows/wf-id/run-id/history?eventID=1&eventType=WorkflowExecutionStarted&referenceType=EventReference] Trigger ActivityClosed State Succeeded Attempt 2 ```
pull Bot
pushed a commit
to amit-writes-code/cli
that referenced
this pull request
Aug 22, 2026
bump server for Nexus Query support includes minor fix for temporalio/api#846 ## Related issues <!-- Closes temporalio#123 --> ## What changed? <!-- Describe what this PR does at a high level. --> ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` **Happy path** ``` $ temporal <command> \ --flag value <expected output> ``` **Error case** ``` $ temporal <command> \ --invalid-combination Error: <expected error message> $ echo $? 1 ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` $ temporal <command-one> ... $ temporal <command-two> --flag <value-from-above> <expected output> ``` Co-authored-by: Alex Stanfield <13949480+chaptersix@users.noreply.github.com>
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 25, 2026
## Related issues <!-- Closes #123 --> Closes: https://temporalio.atlassian.net/browse/COM-241 ## What changed? <!-- Describe what this PR does at a high level. --> Adds `--gcp-cloud-run-scale-down-stabilization-duration` to `temporal worker deployment create-version` and `temporal worker deployment update-version-compute-config`. **UX difference:** the GCP Cloud Run scaler's scale-down stabilization window was previously hard-coded to 90s, so a worker pool running long or bursty activities could be scaled down out from under in-flight work. Users can now configure it: ``` # before: not settable — always 90s # after: temporal worker deployment create-version ... \ --gcp-cloud-run-scale-down-stabilization-duration 10m # hold capacity 10m after demand ``` Details: - The flag is a **duration** (`90s`, `5m`, `10m`), matching the CLI's convention for time-valued flags (`cliext.FlagDuration`, like `--schedule-to-close-timeout`, `--retention`). It joins the existing all-or-none GCP Cloud Run scaler group, so `--gcp-cloud-run-min-instances`, `--gcp-cloud-run-max-instances`, `--gcp-cloud-run-initial-instances`, `--gcp-cloud-run-utilization-target`, and `--gcp-cloud-run-scale-down-stabilization-duration` must all be set together. - Behavior: after the scaler last saw unmet task demand, it waits this long before it may scale the pool down. Defaults to `90s` when unset; `0s` disables the wait. - The CLI converts the duration to milliseconds and sends it under the rate-based scaler's existing `no_sync_quiet_ms` config key, which the server (WCI) already validates and applies — **no server-side change is required**. - `describe-version` surfaces the value as a duration string (JSON `scaleDownStabilization`, e.g. `"5m 0s"`, formatted the same way as schedule durations; the text summary shows the same). ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [x] Breaking changes are marked with 💥 in the PR title and release notes — *no breaking changes; the flag joins an as-yet-unreleased flag group* - [x] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes — *`describe-version` gains an additive `scaleDownStabilizationMs` field; the GCP scaler JSON block is not in a tagged release yet, so no released output changes* **Design** - [x] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [x] New commands follow `temporal <noun> <verb>` structure — *no new commands; flag added to existing commands* - [x] New flags are named after the API concept, not the implementation mechanism — *`scale-down-stabilization-duration` names the behavior (cf. k8s HPA "stabilization window"), not the internal `no_sync_quiet_ms` key* - [x] New flags don't duplicate an existing flag that serves the same purpose - [x] New flags do not have short aliases without strong justification — *no alias* - [x] Experimental features are marked with `(Experimental)` in `commands.yaml` — *both commands already carry a "This is an experimental feature" note* **Help text** (see style guide at the top of `commands.yaml`) - [x] All flags shown in help text and examples are implemented and functional — *the GCP examples include all five flags so they stay copy-pasteable* - [x] Summaries use sentence case and have no trailing period — *no new command summaries* - [x] Long descriptions end with a period and include at least one example invocation - [x] Examples use long flags (`--namespace`, not `-n`), one flag per line - [x] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [x] Results go to stdout; errors and warnings go to stderr - [x] Error messages are lowercase with no trailing punctuation **Tests** - [x] Added functional test(s) (`SharedServerSuite`) — group/negative/sub-millisecond/wrong-provider cases in `TestCreateWorkerDeploymentVersion_Errors`; carried in `...UpdateModes` - [x] Added unit test(s) (`func TestXxx`) — `TestGCPCloudRunScalerDetails`, `TestFormatComputeConfigProto_ScalerBounds` ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless ``` > A full `--gcp-cloud-run-*` create also needs a real Cloud Run worker pool + > service account (the server validates the provider). The error-path checks > below run entirely against the dev server (they fail client-side, before the > RPC). The runtime effect was verified separately via an in-process WCI > integration test. **Happy path** ``` $ temporal worker deployment create-version \ --deployment-name YourDeployment \ --build-id YourBuildId \ --gcp-cloud-run-project YourGcpProject \ --gcp-cloud-run-region us-central1 \ --gcp-cloud-run-worker-pool YourWorkerPool \ --gcp-cloud-run-service-account YourServiceAccount@YourGcpProject.iam.gserviceaccount.com \ --gcp-cloud-run-min-instances 0 \ --gcp-cloud-run-max-instances 10 \ --gcp-cloud-run-initial-instances 2 \ --gcp-cloud-run-utilization-target 0.8 \ --gcp-cloud-run-scale-down-stabilization-duration 5m Successfully created worker deployment version $ temporal worker deployment describe-version \ --deployment-name YourDeployment \ --build-id YourBuildId # summary: gcp-cloud-run (min 0, initial 2, max 10, utilization 0.8, scale-down-stabilization 5m 0s) # --output json includes "scaleDownStabilization": "5m 0s" on the scaler ``` **Error case** ``` # incomplete group (all five must be set together): $ temporal worker deployment create-version \ --deployment-name YourDeployment --build-id YourBuildId \ --gcp-cloud-run-project YourGcpProject --gcp-cloud-run-region us-central1 \ --gcp-cloud-run-worker-pool YourWorkerPool \ --gcp-cloud-run-service-account YourServiceAccount@YourGcpProject.iam.gserviceaccount.com \ --gcp-cloud-run-scale-down-stabilization-duration 5m Error: --gcp-cloud-run-min-instances, --gcp-cloud-run-max-instances, --gcp-cloud-run-initial-instances, --gcp-cloud-run-utilization-target, and --gcp-cloud-run-scale-down-stabilization-duration must be set together $ echo $? 1 # negative (incl. sub-millisecond, which must not silently truncate to 0): $ temporal worker deployment create-version \ --deployment-name YourDeployment --build-id YourBuildId \ --gcp-cloud-run-project YourGcpProject --gcp-cloud-run-region us-central1 \ --gcp-cloud-run-worker-pool YourWorkerPool \ --gcp-cloud-run-service-account YourServiceAccount@YourGcpProject.iam.gserviceaccount.com \ --gcp-cloud-run-min-instances 0 --gcp-cloud-run-max-instances 10 \ --gcp-cloud-run-initial-instances 2 --gcp-cloud-run-utilization-target 0.8 \ --gcp-cloud-run-scale-down-stabilization-duration=-1us Error: --gcp-cloud-run-scale-down-stabilization-duration cannot be negative # sub-millisecond precision is rejected rather than silently rounded: $ temporal worker deployment create-version ... \ --gcp-cloud-run-scale-down-stabilization-duration 500us Error: --gcp-cloud-run-scale-down-stabilization-duration must be a whole number of milliseconds # on a non-GCP provider: $ temporal worker deployment create-version \ --deployment-name YourDeployment --build-id YourBuildId \ --aws-lambda-function-arn YourFunctionArn \ --aws-lambda-skip-role-and-external-id \ --gcp-cloud-run-scale-down-stabilization-duration 5m Error: the Cloud Run scaling flags are only valid with --gcp-cloud-run-worker-pool ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` # Raise the stabilization window on an existing version (all five flags are # re-supplied, since they are one all-or-none group), then confirm via describe. $ temporal worker deployment update-version-compute-config \ --deployment-name YourDeployment --build-id YourBuildId \ --gcp-cloud-run-worker-pool YourWorkerPool \ --gcp-cloud-run-min-instances 0 --gcp-cloud-run-max-instances 10 \ --gcp-cloud-run-initial-instances 2 --gcp-cloud-run-utilization-target 0.8 \ --gcp-cloud-run-scale-down-stabilization-duration 10m Successfully updated worker deployment version compute config $ temporal worker deployment describe-version \ --deployment-name YourDeployment --build-id YourBuildId --output json # scaler now shows "scaleDownStabilization": "10m 0s" ``` Co-authored-by: Claude Opus 4.8 <noreply@anthropic.com>
pull Bot
pushed a commit
to amit-writes-code/cli
that referenced
this pull request
Aug 25, 2026
## Related issues <!-- Closes temporalio#123 --> ## What changed? <!-- Describe what this PR does at a high level. --> Bump to latest for UI server [v2.53.3](https://github.com/temporalio/ui-server/releases/tag/v2.53.3) ~and API [v1.63.5](https://github.com/temporalio/api/releases/tag/v1.63.5)~. **Note**: UI server `v2.53.3` requires go >= `1.26.5`. Bumped to `1.26.5` from `1.26.4`. ## Checklist <!-- Your PR should satisfy all these requirements. However, feel free to remove items that don't apply to the PR. Consider giving this checklist to an AI agent before opening your PR. --> **Stability** - [ ] Breaking changes are marked with 💥 in the PR title and release notes - [ ] Changes to JSON output (`-o json` / `-o jsonl`) are treated as breaking changes **Design** - [ ] This feature does not depend on Cloud-only APIs or behavior (it works against an OSS server) - [ ] New commands follow `temporal <noun> <verb>` structure (e.g. `temporal workflow start`) - [ ] New flags are named after the API concept, not the implementation mechanism (good: `--search-attribute`, bad: `--index-field`) - [ ] New flags don't duplicate an existing flag that serves the same purpose - [ ] New flags do not have short aliases without strong justification - [ ] Experimental features are marked with `(Experimental)` in `commands.yaml` **Help text** (see style guide at the top of `commands.yaml`) - [ ] All flags shown in help text and examples are implemented and functional - [ ] Summaries use sentence case and have no trailing period - [ ] Long descriptions end with a period and include at least one example invocation - [ ] Examples use long flags (`--namespace`, not `-n`), one flag per line - [ ] Placeholder values use `YourXxx` form (`YourWorkflowId`, `YourNamespace`) **Behavior** - [ ] Results go to stdout; errors and warnings go to stderr - [ ] Error messages are lowercase with no trailing punctuation **Tests** - [ ] Added functional test(s) (`SharedServerSuite`) - [ ] Added unit test(s) (`func TestXxx`) where applicable ## Manual tests <!-- Edit the code samples below to provide setup and happy-path and error-path testing instructions. --> **Setup** ``` temporal server start-dev --headless temporal workflow start \ --type YourWorkflowType \ --task-queue YourTaskQueue \ --workflow-id YourWorkflowId ``` **Happy path** ``` $ temporal <command> \ --flag value <expected output> ``` **Error case** ``` $ temporal <command> \ --invalid-combination Error: <expected error message> $ echo $? 1 ``` **Composition** <!-- How might a user combine this with existing commands? e.g. using the output of one command as input to another --> ``` $ temporal <command-one> ... $ temporal <command-two> --flag <value-from-above> <expected output> ```
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.
What was changed
Add port for the Frontend service.
Why?
The change is necessary to allow the service running in the container to be accessible externally.
Checklist
docker build -t temporal:latest . docker run -p 127.0.0.1:8233:8233 --rm -it temporal:latestthen open http://localhost:8233