This is an automated email from the ASF dual-hosted git repository.
villebro pushed a commit to branch main
in repository
https://gitbox.apache.org/repos/asf/superset-kubernetes-operator.git
The following commit(s) were added to refs/heads/main by this push:
new 41de677 release related updates (#399)
41de677 is described below
commit 41de67703747cb4d535949c7e88c8e5882cdcd62
Author: Ville Brofeldt <[email protected]>
AuthorDate: Wed Sep 30 14:32:06 2026 -0700
release related updates (#399)
---
.claude/skills/release-final/SKILL.md | 143 ++++++++++++++++++++++++++++++++++
.claude/skills/release-rc/SKILL.md | 140 +++++++++++++++++++++++++++++++++
.gitattributes | 2 +
.gitignore | 5 +-
docs/contributing/releasing.md | 27 +++++--
docs/reference/releases.md | 17 +++-
scripts/release-finalize.sh | 2 +-
scripts/release-rc.sh | 4 +-
8 files changed, 324 insertions(+), 16 deletions(-)
diff --git a/.claude/skills/release-final/SKILL.md
b/.claude/skills/release-final/SKILL.md
new file mode 100644
index 0000000..4ca905b
--- /dev/null
+++ b/.claude/skills/release-final/SKILL.md
@@ -0,0 +1,143 @@
+---
+name: release-final
+description: >
+ Guide the release manager through finalizing an Apache Superset Kubernetes
+ Operator release after a PMC vote has passed: tallying votes, drafting the
+ [RESULT] email, running release-finalize.sh, pushing the final tag, adding
+ the changelog date, promoting artifacts to dist.apache.org/release, and
+ drafting the [ANNOUNCE] email. Use once a release vote has closed. Never
+ runs git push, svn, or sends email itself — it tells the release manager
+ the exact command to run.
+---
+
+# Finalizing a release
+
+This skill is a guided checklist for the second half of an ASF release: from
PMC vote tally through the `[ANNOUNCE]` email. It starts with no memory of
whatever `/release-rc` session opened the vote — this session asks for whatever
context it needs, since git tags/branches are the durable source of truth and
vote tallies only exist in email. The full authoritative runbook is
`docs/contributing/releasing.md`.
+
+## Ground rules
+
+- **Never run**: `git push`, `svn add`/`svn commit`,
`scripts/release-finalize.sh`, or anything that sends email. Print the exact,
fully-substituted command and wait for the RM to confirm they ran it.
+- **Safe to run directly**: read-only git/gh inspection, and
`scripts/release-email.sh {result,announce}` (pure stdout template generation,
sends nothing).
+- **Safe to edit directly**: `docs/reference/releases.md` to add the release
date. Leave the commit/push to the RM.
+- Nothing here executes `scripts/release-source.sh` promotion or SVN commands
— always print them.
+
+## Steps
+
+### 1. Identify the release being finalized
+
+Confirm the RM is an Apache Superset **committer** (push access to
`apache/superset-kubernetes-operator` is required for steps 5 and 6 below) — if
`/release-rc` already confirmed this for the same RM, no need to re-ask.
+
+Ask which version/RC is being finalized. Help by listing candidates read-only:
+
+```sh
+git tag -l 'v*-rc*'
+git tag -l 'v*' | grep -v -- '-rc'
+```
+
+Suggest RC tags that don't yet have a matching final tag, but let the RM
confirm or override.
+
+### 2. Tally the vote
+
+Ask the RM for the vote tally: who voted, whether they're a binding PMC
member, and +1/0/-1. Also ask when the vote email was sent (or confirm it's
been open ≥72 hours).
+
+Check against ASF release-vote rules:
+
+- At least 3 binding (PMC) +1 votes.
+- No -1 votes.
+- Vote open at least 72 hours.
+
+If the tally doesn't yet qualify, say so clearly — but this is advisory only;
don't block the RM from proceeding if they say it's fine (e.g. they've already
accounted for something you don't have visibility into).
+
+### 3. Draft the result email
+
+Run directly:
+
+```sh
+scripts/release-email.sh result
+```
+
+Show the draft, remind the RM to send it by hand to `[email protected]`
with `[RESULT][VOTE]` in the subject.
+
+### 4. Finalize the tag
+
+`release-finalize.sh` refuses a dirty working tree, and untracked files count.
Check `git status --porcelain` first. If it isn't empty, have the RM stash the
changes (`git stash push -u`) and restore them on a branch off `main` after the
release rather than committing them to the release branch.
+
+Print, filled in:
+
+```sh
+# From the <major>.<minor> branch
+scripts/release-finalize.sh <version>
+```
+
+This tags the exact voted RC commit as the final version — it will refuse if
`HEAD` isn't that commit. Remind the RM not to add any polish commits first;
anything not in the voted RC must not end up under the final tag.
+
+### 5. Push the final tag
+
+Identify the right remote, read-only — don't assume `origin`, since a release
manager developing from a personal fork typically has `origin` pointing at
their fork and a separate remote (commonly `upstream`) pointing at
`[email protected]:apache/superset-kubernetes-operator.git`:
+
+```sh
+git remote -v | grep apache/superset-kubernetes-operator
+```
+
+Use that remote name below; ask the RM if it's ambiguous.
+
+Print:
+
+```sh
+git push <remote> v<version>
+```
+
+This triggers the release workflow that publishes `<version>` and `latest`
images/chart to GHCR.
+
+### 6. Add the release date to the changelog
+
+On `main` (not the release branch — the docs site builds from `main`, and the
release branch's changelog should stay undated to match the voted source), edit
`docs/reference/releases.md`: change `## <version>` to `## <version> - <date>`.
+
+`main` requires a review before merging (branch protection), so this needs a
PR, not a direct push. Print the commands for the RM to run themselves:
+
+```sh
+git checkout main
+git pull <remote>
+git checkout -b docs/<version>-release-date
+# (after the edit)
+git add docs/reference/releases.md
+git commit -m "docs: add release date for <version>"
+git push <remote> docs/<version>-release-date
+gh pr create --title "docs: add release date for <version>" --fill
+```
+
+### 7. Promote source artifacts to dist.apache.org/release
+
+Once the binary release workflow (step 5) has finished successfully, print the
following, run from the `<major>.<minor>` branch with the final tag on `HEAD`:
+
+```sh
+scripts/release-source.sh
+```
+
+This detects the final tag on `HEAD`, reuses the voted RC's signed tarball
bytes under the final filename (preserving signature validity), and regenerates
the SHA-512 checksum. Then print the SVN promotion, with real paths substituted:
+
+```sh
+cd ~/asf/release-superset
+svn up
+mkdir kubernetes-operator-<version>
+cp
/path/to/dist/<version>/apache-superset-kubernetes-operator-<version>.tar.gz{,.asc,.sha512}
\
+ kubernetes-operator-<version>/
+svn add kubernetes-operator-<version>
+svn commit -m "Release Apache Superset Kubernetes Operator <version>"
+```
+
+No wait is needed before this step — it should happen as soon as the binary
workflow is done.
+
+### 8. Wait for the changelog PR, then announce
+
+The announcement links to the release notes on the docs site, so the step 6 PR
must be merged and the docs deployed first. Once it is, run directly from the
`<major>.<minor>` branch (the script reads the final tag from `HEAD`):
+
+```sh
+scripts/release-email.sh announce
+```
+
+Show the draft, remind the RM to send it to `[email protected]` and
`[email protected]`.
+
+### 9. Close out
+
+Confirm all steps are done: final tag pushed, changelog dated on `main`,
artifacts in `release/superset`, announcement sent. The release is complete.
diff --git a/.claude/skills/release-rc/SKILL.md
b/.claude/skills/release-rc/SKILL.md
new file mode 100644
index 0000000..f9b385e
--- /dev/null
+++ b/.claude/skills/release-rc/SKILL.md
@@ -0,0 +1,140 @@
+---
+name: release-rc
+description: >
+ Guide the release manager through cutting a new Apache Superset Kubernetes
+ Operator release candidate: changelog review, running release-rc.sh and
+ release-source.sh, pushing the branch/tag, staging to dist.apache.org/dev,
+ and drafting the [VOTE] email. Use when starting a new release or a new RC
+ for an in-progress release. Never runs git push, svn, or sends email itself
+ — it tells the release manager the exact command to run.
+---
+
+# Cutting a release candidate
+
+This skill is a guided checklist for the first half of an ASF release: from
changelog review through opening the PMC vote. The full authoritative runbook
is `docs/contributing/releasing.md` — this skill walks the release manager (RM)
through it, filling in real values and doing read-only verification, but never
executes any critical/irreversible step itself.
+
+## Ground rules
+
+- **Never run**: `git push`, `svn add`/`svn commit`, `git tag`,
`scripts/release-rc.sh`, `scripts/release-source.sh`, or anything that sends
email. For each of these, print the exact, fully-substituted command (no
placeholders) and wait for the RM to confirm they ran it before moving on.
+- **Safe to run directly**: read-only git/gh inspection (`git status`, `git
tag -l`, `git branch -a`, `git log`, `gh run list`, `gh api .../check-runs`),
grepping `docs/reference/releases.md` / `Makefile`, and
`scripts/release-email.sh vote` (pure stdout template generation, sends
nothing).
+- **Safe to edit directly**: `docs/reference/releases.md` for the changelog
review pass — a normal reversible doc edit. Still leave the `git commit` of
that edit to the RM's own command.
+- If the RM says they already completed a step in a prior session, verify it
read-only (e.g. does the tag exist, does `Makefile` VERSION match) rather than
re-explaining it from scratch.
+
+## Steps
+
+### 1. Establish what's being released
+
+Confirm the RM is an Apache Superset **committer** — this is what grants push
access to `apache/superset-kubernetes-operator`. Without it, everything up
through building the signed tarball still works locally, but step 5 (pushing
the branch/tag) will fail. Committer status is separate from PMC membership: a
non-PMC committer can drive the whole RC/vote mechanics, but the vote itself
still needs a binding `+1` from a PMC member.
+
+Ask the RM which version is being cut (e.g. `0.3.0`) and whether this is the
first RC for a new `<major>.<minor>` or a follow-up RC for one already in
flight. Cross-check with:
+
+```sh
+git tag -l 'v<version>-rc*'
+git branch -a | grep '<major>.<minor>'
+git status
+```
+
+Use this to suggest the next RC number and the branch flow (first RC creates
the `<major>.<minor>` branch from `main`; subsequent RCs reuse the existing
branch). Flag any mismatch against what the RM stated (e.g. they say "rc1" but
`v<version>-rc1` already exists).
+
+### 2. Changelog review
+
+Check whether `docs/reference/releases.md` already has a `## <version>`
heading — `release-rc.sh` will refuse to run without one.
+
+If missing, help the RM do the review pass described in
`docs/contributing/releasing.md` ("Reviewing the Changelog"):
+
+1. Summarize `git log v<previous>..HEAD` into candidate Keep a Changelog
bullets (`Added`/`Changed`/`Deprecated`/`Removed`/`Fixed`/`Security`), dropping
non-noteworthy entries (typo fixes, internal refactors).
+2. Ask the RM to confirm or adjust the summary.
+3. Edit `docs/reference/releases.md` yourself: rename `## Unreleased` to `##
<version>` (no date yet — that's added after the vote passes), add a fresh
empty `## Unreleased` above it, and place the reviewed bullets.
+4. Tell the RM to review the diff and commit it themselves (and, for a first
RC, to do this on the new `<major>.<minor>` branch, not `main`).
+
+### 3. Run release-rc.sh
+
+Print, filled in:
+
+```sh
+scripts/release-rc.sh <version> --expect-rc <n>
+```
+
+This bumps `VERSION`/`Chart.yaml`, runs lint/test/docs/helm checks, commits,
and creates the annotated RC tag locally. Wait for the RM to confirm it ran,
then verify read-only: `git tag -l v<version>-rc<n>`, `grep VERSION Makefile`,
`git branch --show-current`.
+
+Creating the tag here is fine even though CI hasn't run yet — a git tag is
just a local pointer to a commit and doesn't touch the remote. It's the *push*
of the tag (step 5) that has to wait for CI, not its creation.
+
+### 4. Build and sign the source tarball
+
+Print:
+
+```sh
+scripts/release-source.sh
+```
+
+This produces
`dist/<version>-rc<n>/apache-superset-kubernetes-operator-<version>-rc<n>.tar.gz{,.asc,.sha512}`,
signed with the RM's own Apache-registered PGP key, and self-verifies.
+
+### 5. Push branch, wait for CI, push tag
+
+First identify the right remote, read-only — don't assume `origin`, since a
release manager developing from a personal fork typically has `origin` pointing
at their fork and a separate remote (commonly `upstream`) pointing at
`[email protected]:apache/superset-kubernetes-operator.git`:
+
+```sh
+git remote -v | grep apache/superset-kubernetes-operator
+```
+
+Use whatever remote name that resolves to in every command below. If it's
ambiguous (e.g. more than one remote matches, or none do), ask the RM.
+
+Print the two-step sequence, and explain *why* it's two steps: the release
workflow's publish gate (`scripts/verify-release-ci.sh`) reads required checks
off the tagged commit, so pushing the tag before CI is green just makes the
gate wait (or fail) — pushing the branch first lets CI run while the RM stages
other artifacts.
+
+```sh
+git push <remote> <major>.<minor>
+# wait for CI to go green on that branch, then:
+git push <remote> v<version>-rc<n>
+```
+
+If asked, check CI status read-only:
+
+```sh
+gh run list --branch <major>.<minor> --limit 5
+```
+
+If the branch or tag ends up pushed to the wrong remote (e.g. a personal fork)
by mistake, that's harmless and easy to undo — print `git push <wrong-remote>
--delete <branch-or-tag>` for the RM to run.
+
+### 6. Stage to dist.apache.org/dev
+
+Print, with real values substituted (no `${VERSION}`/`${RC}` left as literal
shell variables unless the RM specifically wants a reusable script):
+
+```sh
+cd ~/asf/dev-superset
+mkdir kubernetes-operator-<version>-rc<n>
+cp
/path/to/dist/<version>-rc<n>/apache-superset-kubernetes-operator-<version>-rc<n>.tar.gz{,.asc,.sha512}
\
+ kubernetes-operator-<version>-rc<n>/
+svn add kubernetes-operator-<version>-rc<n>
+svn commit -m "Stage Superset Kubernetes Operator <version>-rc<n>"
+```
+
+Ask the RM for their actual local `dist/` output path and SVN checkout path if
they differ from the defaults, and substitute those instead.
+
+### 7. Summarize what's new
+
+Read the finalized `## <version>` section of `docs/reference/releases.md` and
write:
+
+1. A one-sentence, high-level summary of the release (the overall theme — e.g.
"mostly a security/reliability hardening release" vs. "mostly new features").
+2. A short highlights list grouped by theme (not by Keep a Changelog heading —
group however best conveys what changed, e.g. "Helm/HA", "Kubernetes support",
"security hardening", "bug fixes"). **Explicitly call out every `**Breaking:**`
bullet** — PMC voters need those most.
+
+Only summarize what's actually in the changelog section — don't pull in
internal/dependency-bump commits that were correctly excluded during the
changelog review (step 2); those aren't part of the release notes voters see.
+
+Show both to the RM for review.
+
+### 8. Draft the vote email
+
+Run directly (this only prints a template, sends nothing):
+
+```sh
+scripts/release-email.sh vote
+```
+
+Insert the step 7 summary into the draft — right after the "This is a vote to
release..." line and before the artifact/verification block — so voters get the
highlights inline instead of having to click through to the changelog. Show the
assembled draft to the RM. Remind them:
+
+- Send by hand to `[email protected]` with `[VOTE]` in the subject.
+- The vote must stay open **at least 72 hours**.
+- Needs **at least 3 binding (PMC) +1 votes** and **no -1 votes**.
+
+### 9. Close out
+
+Tell the RM the vote is now open, and that once it closes (passing or not)
they should come back and run `/release-final` to continue.
diff --git a/.gitattributes b/.gitattributes
index 7bb2501..d878111 100644
--- a/.gitattributes
+++ b/.gitattributes
@@ -3,4 +3,6 @@
# (vendor-neutral) file and ships in the release; GEMINI.md is a symlink to it
# and is tool-specific clutter in an official ASF source release. Claude Code
# reads AGENTS.md directly when no CLAUDE.md exists, so no CLAUDE.md is kept.
+# The Claude Code release skills in .claude/ are excluded for the same reason.
GEMINI.md export-ignore
+.claude export-ignore
diff --git a/.gitignore b/.gitignore
index f48e044..156490b 100644
--- a/.gitignore
+++ b/.gitignore
@@ -26,8 +26,9 @@ go.work
*.swo
*~
-# Claude Code / AI tooling
-.claude/
+# Claude Code / AI tooling (shared release skills are tracked)
+.claude/*
+!.claude/skills/
# macOS
.DS_Store
diff --git a/docs/contributing/releasing.md b/docs/contributing/releasing.md
index 42053fc..b9f3f62 100644
--- a/docs/contributing/releasing.md
+++ b/docs/contributing/releasing.md
@@ -134,9 +134,11 @@ scripts/release-source.sh
# Push the release branch first and wait for its CI to go green (release
# branches run the full suite). Then push the tag — the release workflow gates
# publishing on those required checks passing for the tagged commit.
-git push origin 0.2
+# (Substitute your actual remote name for the canonical apache/ repo — see
+# "Pre-requisites for the release manager" above.)
+git push upstream 0.2
# ... wait for CI on the 0.2 branch to complete successfully ...
-git push origin v0.2.0-rc1
+git push upstream v0.2.0-rc1
```
Running the script again from the same release branch increments the RC number
automatically (rc1, rc2, ...).
@@ -156,9 +158,11 @@ A release candidate therefore needs three artifacts staged
on
### Pre-requisites for the release manager
-1. Be a Superset PMC member (binding vote), or coordinate with one if you are
a committer driving the release.
-2. Have a PGP key registered in
`https://dist.apache.org/repos/dist/release/superset/KEYS` and uploaded to the
public keyservers. To add a new key, append the output of `gpg --list-sigs
<fingerprint> && gpg --armor --export <fingerprint>` to `KEYS` in the SVN
checkout below and commit.
-3. Have `svn` checkouts of both ASF dist locations:
+1. Be an Apache Superset **committer** — this is what grants push access to
`apache/superset-kubernetes-operator`, needed to push the release branch and
tags directly. Being a committer is separate from being on the PMC: a committer
without PMC status can drive the whole RC/build/vote mechanics, but the vote
itself still needs a PMC member's binding `+1` to pass (see next item).
+2. Be a Superset PMC member (binding vote), or coordinate with one if you are
a committer driving the release.
+3. Have a PGP key registered in
`https://dist.apache.org/repos/dist/release/superset/KEYS` and uploaded to the
public keyservers. To add a new key, append the output of `gpg --list-sigs
<fingerprint> && gpg --armor --export <fingerprint>` to `KEYS` in the SVN
checkout below and commit.
+4. Have a git remote pointing at
`[email protected]:apache/superset-kubernetes-operator.git` — release branches
and tags must be pushed there. If you develop from a personal fork, that remote
is commonly named `upstream` while `origin` points at your fork; check with
`git remote -v` and substitute the right name for the `git push` commands
below. Pushing a release branch/tag to your fork by mistake is harmless (just
delete it there — `git push <fork-remote> --delete <branch>`), but the rele
[...]
+5. Have `svn` checkouts of both ASF dist locations:
```sh
svn co https://dist.apache.org/repos/dist/dev/superset/ ~/asf/dev-superset
@@ -222,12 +226,19 @@ Because the final tag points at the already-tested RC
commit, the release workfl
scripts/release-finalize.sh 0.2.0
# Push the tag to trigger the release workflow
-git push origin v0.2.0
+git push upstream v0.2.0
```
The release workflow pushes the `0.2.0` and `latest` images to GHCR.
-After the final tag is pushed, add the final release date to
`docs/reference/releases.md` on `main` only (the docs site builds from `main`).
Leave the release-branch changelog undated so it continues to match the voted
source.
+After the final tag is pushed, open a PR against `main` (the docs site builds
from `main`) that carries the release's changelog section with the final date.
For the first RC of a minor release the reviewed `## <version>` section was
committed on the release branch only, so cherry-pick that commit onto `main`
and change the heading to `## <version> - <date>`. Entries that reached
`main`'s `## Unreleased` after the release branch was cut belong to the next
release: keep them under `## Unre [...]
+
+```sh
+section() { awk '/^## 0\.2\.0/{f=1;next} /^## /{f=0} f'; }
+diff <(git show 0.2:docs/reference/releases.md | section) <(section <
docs/reference/releases.md)
+```
+
+Leave the release-branch changelog undated so it continues to match the voted
source.
After the binary release workflow finishes, promote the source artifacts.
`release-source.sh` sees the final tag on `HEAD`, requires a matching RC tag on
the same commit, reuses the staged RC tarball bytes (so the detached signature
stays valid), and regenerates the SHA-512 file under the final filename:
@@ -243,7 +254,7 @@ svn add kubernetes-operator-0.2.0
svn commit -m "Release Apache Superset Kubernetes Operator 0.2.0"
```
-Generate the release announcement after the artifacts have propagated to the
ASF mirror network (typically within 24 hours), review it, then send it to
`[email protected]` and `[email protected]`:
+Generate the release announcement after the changelog PR has merged (the
announcement links to the release notes on the docs site), review it, then send
it to `[email protected]` and `[email protected]`:
```sh
scripts/release-email.sh announce > dist/0.2.0/ANNOUNCE.txt
diff --git a/docs/reference/releases.md b/docs/reference/releases.md
index 0d6db87..bacd0e5 100644
--- a/docs/reference/releases.md
+++ b/docs/reference/releases.md
@@ -25,16 +25,24 @@ This page tracks notable changes in Apache Superset
Kubernetes Operator releases
### Added
+- **Helm `dnsPolicy` and `dnsConfig`.** The Helm chart now exposes `dnsPolicy`
and `dnsConfig` values for the operator manager pod
([#394](https://github.com/apache/superset-kubernetes-operator/pull/394),
[@younsl](https://github.com/younsl)).
+
+### Changed
+
+- Optional string values in the Helm chart (`image.tag`,
`serviceAccount.name`, `logLevel`, `metrics.certSecretName`,
`metrics.serviceMonitor.scrapeTimeout`, `dnsPolicy`,
`podDisruptionBudget.unhealthyPodEvictionPolicy`) now default to `~` (null)
instead of `""`, matching the chart's other unset values. Rendered output is
unchanged, and explicit empty strings are still accepted
([#394](https://github.com/apache/superset-kubernetes-operator/pull/394),
[@younsl](https://github.com/younsl)).
+
+## 0.3.0 - 2026-09-30
+
+### Added
+
- Structured metastore, Valkey, and lifecycle seed-source connection fields
can now be sourced individually from Kubernetes Secret keys, allowing
`Superset` resources to consume provisioner-owned endpoints and credentials
without copying discovered values or assembling a separate connection URI
([#369](https://github.com/apache/superset-kubernetes-operator/pull/369)).
- **Helm `podDisruptionBudget`.** The Helm chart now exposes a
`podDisruptionBudget` value that renders a
[PodDisruptionBudget](https://kubernetes.io/docs/concepts/workloads/pods/disruptions/#pod-disruption-budgets)
for the operator manager pods. It is disabled by default and falls back to
`maxUnavailable: 1` when no bound is set. Rendering fails for integer or
percentage bounds that would leave zero allowed disruptions at the configured
`replicas` (for example `minAvailable: 1` with one [...]
-- **Helm `dnsPolicy` and `dnsConfig`.** The Helm chart now exposes `dnsPolicy`
and `dnsConfig` values for the operator manager pod
([#394](https://github.com/apache/superset-kubernetes-operator/pull/394),
[@younsl](https://github.com/younsl)).
### Changed
- **Helm chart requires leader election for multiple replicas.** Rendering now
fails when `replicas` is greater than 1 and `leaderElection.enabled` is
`false`. Replicas are active/standby behind the [leader election
Lease](https://kubernetes.io/docs/concepts/architecture/leases/#leader-election);
without it every replica reconciles the same `Superset` resources and races on
Jobs, drains, and status. Existing releases with that combination fail `helm
upgrade` until leader election is enab [...]
- Valkey's default port is now applied at runtime, aligning it with the
existing structured-metastore behavior, instead of being stored by CRD
defaulting. Resources that omit both `valkey.port` and `valkey.portFrom`
therefore no longer materialize `port: 6379`, while generated configuration
continues to use port 6379. This permits `portFrom` without a defaulted literal
conflicting at admission
([#369](https://github.com/apache/superset-kubernetes-operator/pull/369)).
-- Kubernetes support now covers the three newest `kind`-published minor
versions instead of two. CI tests Kubernetes 1.37, 1.36, and 1.35 natively,
with the experimental `next` lane disabled again
([#317](https://github.com/apache/superset-kubernetes-operator/pull/317)).
-- Optional string values in the Helm chart (`image.tag`,
`serviceAccount.name`, `logLevel`, `metrics.certSecretName`,
`metrics.serviceMonitor.scrapeTimeout`, `dnsPolicy`,
`podDisruptionBudget.unhealthyPodEvictionPolicy`) now default to `~` (null)
instead of `""`, matching the chart's other unset values. Rendered output is
unchanged, and explicit empty strings are still accepted
([#394](https://github.com/apache/superset-kubernetes-operator/pull/394),
[@younsl](https://github.com/younsl)).
+- Kubernetes support now covers the three newest `kind`-published minor
versions instead of two. CI tests Kubernetes 1.37, 1.36, and 1.35 natively,
with the experimental `next` lane disabled again
([#315](https://github.com/apache/superset-kubernetes-operator/pull/315)).
### Fixed
@@ -43,12 +51,13 @@ This page tracks notable changes in Apache Superset
Kubernetes Operator releases
- The operator no longer crash-loops on clusters where Gateway API is
installed but serves only `v1beta1`: optional-API detection now pins the
version the operator actually uses (`HTTPRoute` v1, `ServiceMonitor` v1)
instead of matching any version of the Kind
([#361](https://github.com/apache/superset-kubernetes-operator/pull/361),
[@villebro](https://github.com/villebro)).
- Component Services of type `NodePort` or `LoadBalancer` that do not pin
`service.nodePort` no longer churn: the operator now preserves the
apiserver-allocated node port across reconciles instead of triggering a
re-allocation each time, which previously changed the external port and broke
external access
([#360](https://github.com/apache/superset-kubernetes-operator/pull/360),
[@villebro](https://github.com/villebro)).
- The operator now requests `update` on `supersets/finalizers`, so
reconciliation no longer fails on clusters with the
`OwnerReferencesPermissionEnforcement` admission plugin enabled (e.g.
OpenShift), where the API server previously rejected the `blockOwnerDeletion`
owner references the operator sets on child resources
([#359](https://github.com/apache/superset-kubernetes-operator/pull/359),
[@villebro](https://github.com/villebro)).
-- The chart no longer rejects top-level values it does not declare, so shared
values files and deploy tooling that injects release metadata no longer fail
schema validation. Nested value blocks are still strictly validated.
+- The chart no longer rejects top-level values it does not declare, so shared
values files and deploy tooling that injects release metadata no longer fail
schema validation. Nested value blocks are still strictly validated
([#366](https://github.com/apache/superset-kubernetes-operator/pull/366),
[@ThomasJLLN](https://github.com/ThomasJLLN)).
### Security
- Every operator-created container (component Deployments, lifecycle task
Jobs, and the create-database init container) now defaults to a hardened
securityContext — `allowPrivilegeEscalation: false`, all capabilities dropped,
and `seccompProfile: RuntimeDefault` — filled per-field only where you have not
set them yourself. This hardens workloads on permissive clusters and satisfies
several of the restricted Pod Security Standard's requirements out of the box;
full restricted compatibilit [...]
- **Breaking:** CRs with `serviceAccount.create=true` (or unset) and
`serviceAccount.name != metadata.name` are now rejected at admission. To use a
pre-existing ServiceAccount with a different name, set
`serviceAccount.create=false`
([#324](https://github.com/apache/superset-kubernetes-operator/pull/324),
[@villebro](https://github.com/villebro)).
+- Instances that had pinned the `superset.apache.org/config-checksum` pod
annotation roll once on upgrade as the operator's computed checksum reasserts
itself, closing a gap where a pinned annotation could freeze out config and
`SECRET_KEY` rotations while status misreported as reconciled
([#331](https://github.com/apache/superset-kubernetes-operator/pull/331),
[@villebro](https://github.com/villebro)).
- **Breaking:** Valkey cache and results-backend `keyPrefix` values are now
constrained to `^[A-Za-z0-9._:-]*$` (max 128 characters); values containing
spaces, slashes, or other characters outside that set are rejected. The safer
rendering also causes a one-time config-checksum change and pod roll on upgrade
([#325](https://github.com/apache/superset-kubernetes-operator/pull/325),
[@villebro](https://github.com/villebro)).
- Seed `excludeTables`, `excludeTableData`, and `postSeedSQL` values are now
passed literally to generated seed scripts; values that previously relied on
shell expansion no longer expand
([#325](https://github.com/apache/superset-kubernetes-operator/pull/325),
[@villebro](https://github.com/villebro)).
- **Breaking:** Celery Flower is no longer published on the Ingress/Gateway
surface in `Production` by default. Flower's default command ships without
authentication and its dashboard discloses task names and arguments — for
Superset, other users' async SQL Lab statements and alert/report payloads. In
`Production` (the default) Flower is fanned out onto the end-user host — and
its port opened in the built-in NetworkPolicy — only when you explicitly set
`celeryFlower.service.gatewayPath`; [...]
diff --git a/scripts/release-finalize.sh b/scripts/release-finalize.sh
index abd64b5..3ead12f 100755
--- a/scripts/release-finalize.sh
+++ b/scripts/release-finalize.sh
@@ -81,6 +81,6 @@ echo ""
echo -e "${BOLD}Release ${TAG} is tagged.${RESET}"
echo ""
echo "Next steps:"
-echo " 1. Push the tag: git push origin ${TAG}"
+echo " 1. Push the tag: git push <remote> ${TAG}"
echo ""
echo "The release workflow will push the ${VERSION} and latest images to GHCR."
diff --git a/scripts/release-rc.sh b/scripts/release-rc.sh
index 5af35ad..d719844 100755
--- a/scripts/release-rc.sh
+++ b/scripts/release-rc.sh
@@ -182,6 +182,8 @@ echo ""
echo "Next steps:"
echo " 1. Review the commit: git log --oneline -3"
echo " 2. Build and verify source artifacts: scripts/release-source.sh"
-echo " 3. Push branch + tag only after artifact verification: git push
origin ${BRANCH} ${TAG}"
+echo " 3. Push the branch, wait for its CI to go green, then push the tag:"
+echo " git push <remote> ${BRANCH}"
+echo " git push <remote> ${TAG}"
echo ""
echo "The release workflow will build and push the ${VERSION}-rc${RC_N} image
to GHCR."
