chore: release 9.0.1 — GlitchTip 6.2.3, Valkey subchart 0.11.0

David Burkerequested to merge
chore/valkey-0.11.0-release-9.0.1 into master

Summary

Release 9.0.1: bumps appVersion to GlitchTip 6.2.3 and the bundled Valkey subchart from 0.9.4 to 0.11.0 (Valkey 9.0.2 → 9.1.1).

I diffed the two Valkey chart tarballs to check for breaking changes before taking the bump. There are none for this chart — no values keys were removed or renamed upstream, and all four ci/*-values.yaml scenarios render and helm lint clean.

Worth knowing about the Valkey upgrade:

  • The Valkey pod rolls on upgrade. Upstream refactored the health probes into a valkey.healthProbes helper, which changes the probe exec from ["sh","-c","valkey-cli ping"] to a direct ["valkey-cli","ping"] argv. Functionally identical, but it's a pod-spec change. With the chart default valkey.dataStorage.enabled: false that flushes the cache — users logged out, pending background tasks lost. No action required, just pick an upgrade window.
  • New valkey.startupProbe / livenessProbe / readinessProbe blocks are now configurable. Defaults reproduce the previous behavior (readiness stays off), so nothing to migrate. These do not collide with this chart's root-level livenessProbe/readinessProbe, which are web-pod values in a separate namespace.
  • New valkey.runtimeClassName for selecting a container runtime (e.g. gvisor, kata-containers).
  • valkey.auth.usersExistingSecret now goes through tpl. Additive; only matters if a secret name literally contains {{.
  • Env var VALKEY_LOGLEVEL → VALKEY_LOG_LEVEL inside the subchart. The valkey.valkeyLogLevel values key is unchanged, so no impact.

On the valkey-operator

The valkey-io/valkey-helm repo now publishes three charts from one index (valkey, valkey-operator, valkey-resources), versioned independently. We depend on valkey, which is still actively released and still the chart this bump targets — the operator is opt-in and changes nothing here. The one related note is that the valkey chart will not support Valkey cluster mode; that is moving to the operator-based chart. We use standalone, so this does not affect us.

Also in this MR

Removes valkey.replicaCount from values.yaml. The Valkey subchart has never had a replicaCount key — not in 0.9.4 either — so the setting was silently ignored (the subchart schema has no additionalProperties: false). Its Deployment hardcodes replicas: 1; scaling is controlled by valkey.replica.enabled / valkey.replica.replicas. Rendered output is byte-identical without it; I verified the Valkey Deployment still comes out at replicas: 1.

Testing

  • helm lint ./charts/glitchtip --set valkey.enabled=false — passes
  • helm template across all four ci/*-values.yaml scenarios — all render (helm 4.2.3)
  • Confirmed the Valkey Deployment still renders replicas: 1 after removing the dead key

Upstream bug found (not fixed here)

valkey/templates/statefulset.yaml in 0.11.0 emits a literal tab after apiVersion: v1 in volumeClaimTemplates, and it lands in the rendered output. helm, kubectl apply --dry-run=client and kubeconform all tolerate it, but it is not spec-valid YAML — PyYAML rejects it outright, so strict yamllint/policy tooling could choke. It only affects users who set valkey.replica.enabled=true; our default Deployment path and all CI scenarios are unaffected. I'll report it upstream separately.

AI disclosure: Claude Code performed the subchart diff, wrote the CHANGELOG entry and this description, and ran the lint/template verification. Reviewed by me before pushing.

🤖 Generated with Claude Code

Merge request reports