## Summary
- The admin-tools container CMD runs `sleep infinity` in the foreground,
which blocks the shell from processing signal traps
- SIGTERM is never handled, so the container hangs until the kubelet
termination deadline before being force-killed
- Background the sleep and use `wait` as the foreground command instead
-- `wait` is a shell builtin that gets interrupted by signals, allowing
the trap handler to exit immediately
## Test plan
Run the following to compare signal handling before and after:
```bash
#!/usr/bin/env bash
set -euo pipefail
STOP_TIMEOUT=5
echo "=== OLD: sleep infinity in foreground (should hang for ${STOP_TIMEOUT}s) ==="
docker run -d --name admin-tools-old alpine:latest \
sh -c "trap exit INT HUP TERM; sleep infinity" >/dev/null
sleep 1
echo "Container running. Sending SIGTERM..."
start=$(date +%s)
docker stop --timeout "$STOP_TIMEOUT" admin-tools-old >/dev/null
elapsed=$(( $(date +%s) - start ))
echo "Stopped in ${elapsed}s (expected: ${STOP_TIMEOUT}s -- signal was ignored)"
docker rm admin-tools-old >/dev/null
echo ""
echo "=== NEW: sleep infinity & wait (should exit immediately) ==="
docker run -d --name admin-tools-new alpine:latest \
sh -c "trap exit INT HUP TERM; sleep infinity & wait" >/dev/null
sleep 1
echo "Container running. Sending SIGTERM..."
start=$(date +%s)
docker stop --timeout "$STOP_TIMEOUT" admin-tools-new >/dev/null
elapsed=$(( $(date +%s) - start ))
echo "Stopped in ${elapsed}s (expected: 0s -- signal was handled)"
docker rm admin-tools-new >/dev/null
```
Expected output:
```
=== OLD: sleep infinity in foreground (should hang for 5s) ===
Container running. Sending SIGTERM...
Stopped in 5s (expected: 5s -- signal was ignored)
=== NEW: sleep infinity & wait (should exit immediately) ===
Container running. Sending SIGTERM...
Stopped in 0s (expected: 0s -- signal was handled)
```
## What changed?
- Update Go 1.26.0 to 1.26.2
- Run `make update-dependencies` (skipped
`github.com/olekukonko/tablewriter`)
- Updated Docker Alpine version to 3.23.4
## Why?
Address CVEs
## How did you test it?
- [ ] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
## Potential risks
## What changed?
- Centralized Alpine base image version to a single source of truth in
\`docker/docker-bake.hcl\` (\`ALPINE_TAG\`).
- Updated Docker targets to consume \`ALPINE_TAG\` from bake args
(removed duplicated Dockerfile defaults).
- Updated build action handling so an empty \`alpine-tag\` input does
not override bake defaults.
- Simplified manual Docker workflow inputs by removing platform/snapshot
toggles and hardcoding snapshot builds + multi-arch behavior for manual
runs.
- Clarified manual workflow input descriptions (\`cli-version\`,
\`alpine-tag\`, and push destination).
## Why?
- Avoid Alpine version drift across multiple files.
- Make manual dispatch safer and less error-prone (empty Alpine input
should use default, not fail with \`alpine:\`).
- Reduce confusing/no-op options in manual workflow while keeping
release behavior unchanged.
## Updating versions
**Alpine base image** — edit the \`ALPINE_TAG\` default in
\`docker/docker-bake.hcl\` (line 41):
```hcl
variable "ALPINE_TAG" {
default = "3.23.3" # <-- change this
}
```
**Temporal CLI** — edit the \`defaultCliVersion\` constant in
\`.github/actions/build-docker-images/scripts/main.go\` (line 17):
```go
// defaultCliVersion should be updated to the latest cli version
const defaultCliVersion = "1.6.1" // <-- change this
```
To pin a different version for a one-off manual run without changing the
default, pass it via the \`cli-version\` workflow dispatch input
instead.
## Validation
- Triggered manual workflow against branch and confirmed branch is
available on upstream.
- Verified bake config resolves default Alpine tag from
\`docker/docker-bake.hcl\`.
## Summary
Bumps dependencies to address security CVEs on `main`:
- **CVE-2026-33186 (CRITICAL)**: `google.golang.org/grpc` v1.72.2 →
v1.79.3 — authorization bypass via missing leading `/` in `:path` header
- **CVE-2026-22184 (HIGH)**: Alpine `zlib` 1.3.1-r2 → 1.3.2-r0 — global
buffer overflow in `untgz` utility
Note: The other two CVEs from the v1.30.2 security review are already
addressed on `main`:
- otel/sdk v1.40.0 — already landed via #9442
- Go stdlib — `main` is on Go 1.26.0 (separate release series)
## Risk assessment
- **grpc v1.72.2 → v1.79.3**: 7 minor version jump with ~23 transitive
dependency upgrades. Builds cleanly. Same bump successfully applied to
`release/v1.30.x` in #9610.
- **zlib**: Alpine package upgrade via `apk upgrade --no-cache zlib` in
both server and admin-tools Dockerfiles.
## Test plan
- [ ] CI passes
Made with [Cursor](https://cursor.com)
## What changed?
Add full commit SHA tags alongside the existing short SHA tags for OSS
`server` and `admin-tools` images. The Docker build action now emits
both tag forms, Docker bake publishes both tags, and the manual Docker
build summary shows the short SHA tag, full SHA tag, and branch tag from
action outputs.
## Why?
This repo has outgrown 7-character SHA uniqueness, so short SHA tags can
collide. Since release engineering automation publishes and consumes
these image tags across workflows, using full SHAs keeps artifact
selection deterministic while preserving short tags for compatibility.
## How did you test it?
- [x] built
- [ ] run locally and tested manually
- [ ] covered by existing tests
- [ ] added new unit test(s)
- [ ] added new functional test(s)
---------
Co-authored-by: Alex Stanfield <13949480+chaptersix@users.noreply.github.com>
## Summary
- Bump Alpine base image tag default to 3.23.3 for server/admin-tools
images.
- Update defaults in docker build bake args and manual build workflows.
## What changed?
* Remove redundant docker image platform
* Remove Multi Arch build PR trigger
Th Multi Arch build PR build trigger was added to validate multi arch
builds in PR. It's likely overkill now. There is a single arch docker
build on each PR for the feature tests
## What changed?
* updates goreleaser to v2
* add GHA for build admin-tools and server images within this repo.
`docker-builds` will only be used for building pre 1.30 images
* added GHA to promote docker builds from temporaliotest to temproalio
docker image repos
* trivy security scanning gates for image promotion (pulled rom
docker-builds repo). The gate can be overridden
## Why?
* we decided to move away from building images in `docker-builds`. The
complexity is not needed
* updates goreleaser to v2 because the v1 definitions might be no longer
supported at some point and this is a good time to do it
* I used go scripts for the more complex flows instead of js or bash so
we don't introduce another language contributors need to be familiar
with. IMO the js or bash I did use it simple enough to understand.
## How did you test it?
It passes in CI.
## Potential risks
* these build pipelines are only compatible with the new docker images.
* merging this PR may break our nightly tests. Will double check before
merging
* flows that are not triggered by opening a PR are untested and
therefore not completely validated
## What Changed
This PR introduces a new `--config-file` flag (and the
`TEMPORAL_SERVER_CONFIG_FILE_PATH ` environment variable) to remove the
dependency on `dockerize` in the Temporal server Docker image.
When a configuration file is specified using either the CLI flag or the
environment variable, the server will load configuration **only** from
that file.
Users who want templating behavior similar to `dockerize` can enable it
by adding the comment `# enable-template` at the top of the
configuration file.
---
### Key Changes
1. **New `--config-file` flag:**
* Adds a global `--config-file` flag that accepts a path to a single
configuration file (absolute or relative to the project root).
* Can also be set via the `TEMPORAL_SERVER_CONFIG_FILE_PATH `
environment variable.
2. **Deprecated legacy flags:**
* The `--config`, `--env`, and `--zone` flags are now marked as
**deprecated** in CLI help text.
* These flags still work for backward compatibility.
3. **Embedded config template:**
* The `config_template.yaml` file is now embedded in the binary to
support loading configuration from environment variables.
* Templating is supported if the file includes the `# enable-template`
comment at the top.
4. **Templating support:**
* Configuration files can use templating by including `#
enable-template` at the beginning of the YAML file.
---
### Configuration Loading Priority (Highest to Lowest)
1. **`--config-file` specified** → Load that specific file
2. **`--config`, `--env`, or `--zone` specified** → Load from
configuration directory (**deprecated**)
3. **No configuration specified** → Load from embedded template using
environment variables (default)
---
### Expected Behavior
The following examples illustrate how the new configuration loading
logic behaves:
* **Default behavior:**
Running `temporal start` without flags loads configuration from
environment variables only using the embedded template.
* **Using `--config-file`:**
`temporal --config-file=/path/to/config.yaml start` loads configuration
from the specified file path.
* **Using `TEMPORAL_SERVER_CONFIG_FILE_PATH`:**
Setting `TEMPORAL_SERVER_CONFIG_FILE_PATH=/path/to/config.yaml temporal
start` has the same effect as using the flag.
* **Validation and error handling:**
The CLI returns clear error messages when conflicting flags or
environment variables are used, or when a specified file does not exist.
---
## Breaking Change
The default behavior of `temporal start` has changed.
It now loads configuration **from environment variables** instead of
using a default template path.
---------
Co-authored-by: Alex Stanfield <chaptersix@users.noreply.github.com>
Co-authored-by: michaely520 <michaely520@users.noreply.github.com>
Co-authored-by: Yichao Yang <yichao@temporal.io>
Co-authored-by: David Reiss <david@temporal.io>
## What changed?
Added support for parsing permissions from JWT claim using regular
expression
## Why?
Default JWT Claim Mapper expects permission in form `namespace:role`. If
it's not possible to configure JWT issuer to follow `namespace:role`
permissionsPattern can be set to regular expression with named groups to
parse permission. More details in issue gh-7560
## How did you test it?
- Unit tests
- Local tests
- Self hosted environment (ongoing)
## Potential risks
This change is only activated if new configuration is provided
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
WIP
## Is hotfix candidate?
No
## What changed?
<!-- Describe what has changed in this PR -->
The bindOnIP values in the docker configuration template is wrapped with
a string.
## Why?
<!-- Tell your future self why have you made these changes -->
When attempting to listen on IPv6 in Docker without this change present,
the colons in the IP address are interpreted as part of the YAML. The
strings added allow IPv6 bind addresses to work properly.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
I have not verified this change but I came across this issue when trying
to configure Temporal for IPv6, and this fix is similar as for other
projects I've come across.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
The Temporal server docker image would be broken.
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
N/A
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
Yes
## What changed?
https://github.com/temporalio/temporal/pull/6155 introduced the config
value `allowedAuthenticators`. This PR updates the
`temporal-cassandra-tool` to use this config value. It also updates
`config_template.yaml` so that the config value can be set in docker
images as well.
## Why?
Cassandra supports several authenticators to verify the login
credentials. Gocql implements a subset of them as [default allowed list
of
authenticators](34fdeebefc/conn.go (L27)).
It allows customization of this list to allow supporting additional
authenticators.
So with this change Temporal can connect to Cassandra clusters that have
authenticators other than the default ones provided by Gocql.
## How did you test it?
Ran `./temporal-cassandra-tool` and verified that it picked up the
values in environment variable `CASSANDRA_ALLOWED_AUTHENTICATORS`.
Couldn't test docker build since it's in a different repo.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Documentation
<!-- Have you made sure this change doesn't falsify anything currently
stated in `docs/`? If significant
new behavior is added, have you described that in `docs/`? -->
## Is hotfix candidate?
No
---------
Co-authored-by: Rob Holland <rob@temporal.io>
Also changed the semantics of cluster info's HTTPAddress to just be the
address, and not include the scheme.
We now use the TLS configuration to derive the URL scheme.
## What changed?
<!-- Describe what has changed in this PR -->
Remove support for standard visibility
## Why?
<!-- Tell your future self why have you made these changes -->
Standard visibility is deprecated.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
## What changed?
<!-- Describe what has changed in this PR -->
Remove support for Cassandra as visibility store.
Updated integration tests that used Cassandra visibility to use
Elasticsearch.
## Why?
<!-- Tell your future self why have you made these changes -->
Deprecating Cassandra visibility.
## How did you test it?
<!-- How have you verified this change? Tested locally? Added a unit
test? Checked in staging env? -->
Updated tests.
## Potential risks
<!-- Assuming the worst case, what can be broken when deploying this
change to production? -->
No.
## Is hotfix candidate?
<!-- Is this PR a hotfix candidate or does it require a notification to
be sent to the broader community? (Yes/No) -->
No.
## What changed?
Add the constant `postgres12_pgx` in the docker configuration template
Related PR : https://github.com/temporalio/docker-builds/pull/179
## Why?
Support for `jackc/pgx` was added in #4913 but it wasn't possible to use
it within the provided configuration template
## How did you test it?
Checked template generation with `dockerize`
## Potential risks
Low risks, doesn't change default behavior
## Is hotfix candidate?
No
* Revert "Fix auth plugin configuration to match the new SQLAuthPlugin config block (#2844)"
This reverts commit 5acbdd70b1.
* Revert rds-iam-auth - current drivers dont support authentication callbacks
Signed-off-by: Alexander Mays <alex@eastside.io>
Signed-off-by: Alexander Mays <alex@eastside.io>
Added:
A new environment variable to the CLI: SQL_AUTH_PLUGIN=rds-iam-auth
A new flag arg to the CLI: --sql-auth-plugin rds-iam-auth
2 new docker template variables: authPlugin: {{ default .Env.SQL_AUTH_PLUGIN "" }} and authPlugin: {{ default .Env.SQL_VIS_AUTH_PLUGIN "" }}
A new SQL configuration attribute authPlugin
Dockerize moved from using Glock to Go modules and introduced
go.mod and go.sum files into the repository.
Therefore, the Go module initialization command has to be removed
from the `base-server` Dockerfile as it breaks the build.
See: 6f92b85658
