chore(reloader): bump chart constraint from the dead 1.x line to 2.2.x #428

Merged
k.renner merged 1 commits from claude-bot/reloader-chart-2x into master 2026-07-27 19:22:43 +00:00
Member

Part of the issue round for #426 (infrastructure update audit).

The >=1.0.0 <2.0.0 ceiling had reached its practical maximum: chart 1.3.0 (app v1.3.0) is the last 1.x ever published, so the bound was holding us on a dead line while upstream moved to app v1.4.19. This is the one item the audit called out as most worth a deliberate look.

Verified before bumping (not taken on the audit bot's word)

Check Result
Breaking change at 1.x→2.0.0 Only deployment.image.* → top-level image.*. This HelmRelease sets values: {}, so neither key is in play — drop-in.
helm template --version 2.2.14 w/ default values rc=0, renders image ghcr.io/stakater/reloader:v1.4.19
ClusterRole rules 1.3.0 vs 2.2.14 byte-identical — cluster-wide privileges of this restart-authority controller do not change
New in 2.x a namespace-scoped Role (configmaps list/get/watch/create/update) for leader election — additive only
kubectl kustomize kubernetes/infrastructure renders 199 resources, HelmRelease picks up the new constraint

Floored at 2.2.0 rather than 2.0.0 to skip the early 2.0/2.1 line outright. Resolves to 2.2.14 today.

⚠️ Note for future edits (also recorded in the manifest comment): Helm silently drops renamed/orphaned values keys instead of erroring. If image overrides are ever added here, check them against the chart schema rather than trusting a clean apply.

Blast radius

Reloader itself rolls. The 7 reloader-annotated workloads (apps/external-dns, apps/woodpecker-agent, apps/woodpecker-server, home-assistant/home-assistant, home-assistant/shelly-manager, monitoring/pve-exporter, paperless/paperless) are not restarted by a controller upgrade alone.

Refs #426

🤖 Generated with Claude Code

Part of the issue round for #426 (infrastructure update audit). The `>=1.0.0 <2.0.0` ceiling had reached its practical maximum: chart **1.3.0 (app v1.3.0) is the last 1.x ever published**, so the bound was holding us on a dead line while upstream moved to app **v1.4.19**. This is the one item the audit called out as most worth a deliberate look. ### Verified before bumping (not taken on the audit bot's word) | Check | Result | |---|---| | Breaking change at 1.x→2.0.0 | Only `deployment.image.*` → top-level `image.*`. This HelmRelease sets `values: {}`, so neither key is in play — drop-in. | | `helm template --version 2.2.14` w/ default values | rc=0, renders image `ghcr.io/stakater/reloader:v1.4.19` | | ClusterRole rules 1.3.0 vs 2.2.14 | **byte-identical** — cluster-wide privileges of this restart-authority controller do not change | | New in 2.x | a namespace-scoped `Role` (configmaps list/get/watch/create/update) for leader election — additive only | | `kubectl kustomize kubernetes/infrastructure` | renders 199 resources, HelmRelease picks up the new constraint | Floored at **2.2.0** rather than 2.0.0 to skip the early 2.0/2.1 line outright. Resolves to 2.2.14 today. ⚠️ Note for future edits (also recorded in the manifest comment): Helm silently **drops** renamed/orphaned values keys instead of erroring. If image overrides are ever added here, check them against the chart schema rather than trusting a clean apply. ### Blast radius Reloader itself rolls. The 7 reloader-annotated workloads (`apps/external-dns`, `apps/woodpecker-agent`, `apps/woodpecker-server`, `home-assistant/home-assistant`, `home-assistant/shelly-manager`, `monitoring/pve-exporter`, `paperless/paperless`) are **not** restarted by a controller upgrade alone. Refs #426 🤖 Generated with [Claude Code](https://claude.com/claude-code)
claude-bot added 1 commit 2026-07-27 19:19:22 +00:00
chore(reloader): bump chart constraint from the dead 1.x line to 2.2.x
ci/woodpecker/pr/pr-review Pipeline was successful
ci/woodpecker/pr/ci-scripts-test Pipeline was successful
3a001c5f46
The `>=1.0.0 <2.0.0` ceiling had reached its practical maximum: chart 1.3.0
(app v1.3.0) is the last 1.x ever published, so the bound was holding the
cluster on a dead line while upstream had moved on to app v1.4.19.

Verified before bumping:
- The only breaking change at the 1.x->2.0.0 boundary is the relocation of
  `deployment.image.*` to top-level `image.*`. This HelmRelease sets
  `values: {}`, so neither key is in play and the bump is a drop-in.
- `helm template stakater/reloader --version 2.2.14` renders cleanly with
  default values (rc=0, image v1.4.19).
- ClusterRole rules are byte-identical between 1.3.0 and 2.2.14 — the
  cluster-wide privileges of this restart-authority controller do not change.
  2.x additionally ships a namespace-scoped Role (configmaps
  list/get/watch/create/update) used for leader election. Additive only.
- `kubectl kustomize kubernetes/infrastructure` renders 199 resources with the
  HelmRelease resolving to the new constraint.

Floored at 2.2.0 rather than 2.0.0 to skip the early 2.0/2.1 line outright.
Resolves to 2.2.14 today.

Blast radius on upgrade: reloader itself rolls; the 7 annotated workloads
(apps/external-dns, apps/woodpecker-agent, apps/woodpecker-server,
home-assistant/home-assistant, home-assistant/shelly-manager,
monitoring/pve-exporter, paperless/paperless) are not restarted by a
controller upgrade alone.

Refs #426

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
review-bot left a comment
Member

🤖 Automated review — model CLI default (complexity: complex), commit 3a001c5f46faabdde0ea6d8e6de8826d2254686e.

Advisory review by the review-bot pipeline. It never approves; a human merges. Push new commits to get a fresh review.


Summary

Single-file change to kubernetes/infrastructure/reloader/helmrelease.yaml: bumps the Flux HelmRelease chart version constraint for Stakater Reloader from >=1.0.0 <2.0.0 to >=2.2.0 <3.0.0, with an expanded comment documenting the rationale and the one breaking change at the 1.x→2.0.0 boundary (deployment.image.* → image.*, not used here since values: {}). No blocking issues found.

🟡 Suggestions

  • RBAC/leader-election claim is unverifiable in this checkout. The PR body states the chart's ClusterRole is byte-identical between 1.3.0 and 2.2.14, and that 2.x adds only a namespace-scoped Role for leader election (additive). This repo doesn't vendor the chart, and this environment has no helm binary or network access, so I could not independently reproduce helm template/helm diff to confirm those claims — I'm relying on the author's verification table. This is low risk (a namespace-scoped Role for leader election is a standard, narrowly-scoped addition for controllers), but worth a helm template --version 2.2.14 -f <(echo 'values: {}') sanity check by a reviewer with registry access before merge, since it's the one part of the change that isn't visible in the diff itself.
  • The PR body flags that the 7 reloader-annotated workloads won't be restarted by this controller upgrade alone — worth confirming that's actually the intended rollout (i.e., no separate follow-up needed to actually exercise the new Reloader version against them), though that's out of scope for this diff.

Tests

No tests apply — this is a Flux HelmRelease version-constraint change with no accompanying logic. The change is self-verifying at reconcile time (Flux will fail to resolve/install if the constraint or chart is broken), which is the appropriate validation mechanism for this kind of GitOps change. The PR body documents manual helm template and kubectl kustomize verification, which is reasonable for this repo's conventions.

Recommendation

Looks reasonable — no blocking issues; comments above are optional.

🤖 **Automated review** — model `CLI default` (complexity: complex), commit `3a001c5f46faabdde0ea6d8e6de8826d2254686e`. > Advisory review by the `review-bot` pipeline. It never approves; a human merges. Push new commits to get a fresh review. --- ## Summary Single-file change to `kubernetes/infrastructure/reloader/helmrelease.yaml`: bumps the Flux `HelmRelease` chart version constraint for Stakater Reloader from `>=1.0.0 <2.0.0` to `>=2.2.0 <3.0.0`, with an expanded comment documenting the rationale and the one breaking change at the 1.x→2.0.0 boundary (`deployment.image.*` → `image.*`, not used here since `values: {}`). No blocking issues found. ## 🟡 Suggestions - **RBAC/leader-election claim is unverifiable in this checkout.** The PR body states the chart's `ClusterRole` is byte-identical between 1.3.0 and 2.2.14, and that 2.x adds only a namespace-scoped `Role` for leader election (additive). This repo doesn't vendor the chart, and this environment has no `helm` binary or network access, so I could not independently reproduce `helm template`/`helm diff` to confirm those claims — I'm relying on the author's verification table. This is low risk (a namespace-scoped `Role` for leader election is a standard, narrowly-scoped addition for controllers), but worth a `helm template --version 2.2.14 -f <(echo 'values: {}')` sanity check by a reviewer with registry access before merge, since it's the one part of the change that isn't visible in the diff itself. - The PR body flags that the 7 reloader-annotated workloads won't be restarted by this controller upgrade alone — worth confirming that's actually the intended rollout (i.e., no separate follow-up needed to actually exercise the new Reloader version against them), though that's out of scope for this diff. ## Tests No tests apply — this is a Flux `HelmRelease` version-constraint change with no accompanying logic. The change is self-verifying at reconcile time (Flux will fail to resolve/install if the constraint or chart is broken), which is the appropriate validation mechanism for this kind of GitOps change. The PR body documents manual `helm template` and `kubectl kustomize` verification, which is reasonable for this repo's conventions. ## Recommendation Looks reasonable — no blocking issues; comments above are optional. <!-- pr-review:sha=3a001c5f46faabdde0ea6d8e6de8826d2254686e -->
k.renner merged commit 211d661c75 into master 2026-07-27 19:22:43 +00:00
Sign in to join this conversation.