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.
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.
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)
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>
🤖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 -->
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Part of the issue round for #426 (infrastructure update audit).
The
>=1.0.0 <2.0.0ceiling 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)
deployment.image.*→ top-levelimage.*. This HelmRelease setsvalues: {}, so neither key is in play — drop-in.helm template --version 2.2.14w/ default valuesghcr.io/stakater/reloader:v1.4.19Role(configmaps list/get/watch/create/update) for leader election — additive onlykubectl kustomize kubernetes/infrastructureFloored 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
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>🤖 Automated review — model
CLI default(complexity: complex), commit3a001c5f46faabdde0ea6d8e6de8826d2254686e.Summary
Single-file change to
kubernetes/infrastructure/reloader/helmrelease.yaml: bumps the FluxHelmReleasechart version constraint for Stakater Reloader from>=1.0.0 <2.0.0to>=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 sincevalues: {}). No blocking issues found.🟡 Suggestions
ClusterRoleis byte-identical between 1.3.0 and 2.2.14, and that 2.x adds only a namespace-scopedRolefor leader election (additive). This repo doesn't vendor the chart, and this environment has nohelmbinary or network access, so I could not independently reproducehelm template/helm diffto confirm those claims — I'm relying on the author's verification table. This is low risk (a namespace-scopedRolefor leader election is a standard, narrowly-scoped addition for controllers), but worth ahelm 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.Tests
No tests apply — this is a Flux
HelmReleaseversion-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 manualhelm templateandkubectl kustomizeverification, which is reasonable for this repo's conventions.Recommendation
Looks reasonable — no blocking issues; comments above are optional.