Your monitoring stack is eleven major versions behind. A jump straight to the newest release would break it. A bump of one patch at a time would take a year. The assistant reads every changelog in between. It checks which breaking changes actually touch your configuration. Then it proposes the biggest safe step.
The daily upgrade scan starts from the live HelmReleases, OCI sources and container images. It links each one back to the file in git that declares it. The assistant treats a release that exists only in git, or only in the cluster, differently from one that is in both.
Here the assistant finds kube-prometheus-stack, pinned at
61.3.2. Your team has tuned its values block over
the years.
The assistant fetches the index.yaml of the chart (or lists OCI tags).
It uses your repository credentials where needed. It drops pre-releases.
It skips versions that you or we marked known-bad.
Container images get the same treatment through Docker Hub, GHCR and your own registries.
Release notes come from GitHub releases. If a project
publishes no releases, they come from CHANGELOG.md / UPGRADE.md.
The assistant extracts each breaking change and sorts it into a class.
The classes are a values rename, a required step, a CRD change and a
migration path.
If the assistant cannot fetch a changelog, the MR says so in a banner and the risk goes up. The assistant never reports missing evidence as "no breaking changes".
The assistant checks each finding against your HelmRelease values. It also checks against a render of the chart with those values. Helm never installs the versions in between. So a change that 63 introduces and 64 reverts is irrelevant to a jump past 64.
Required-step changes are hard stops. Your values do not change that.
The rule is simple, and the MR states it. If breaking-change evidence is in range, the assistant stops just before it and quotes the excerpt. If there is none, it goes up to a year of releases in one step.
Here the first stop that applies is 67.0.0, so the
target is 66.7.1. That is five major versions in one reviewed
MR. The next step becomes its own MR after you merge this one.
The assistant runs helm template at the current and at the target
version with your values. It then compares the two outputs. This shows what the version string hides, such as new CRDs,
changed selectors and a container that gains an argument.
Changes to load-bearing fields raise the risk, and the MR calls them out. These fields are container specs, Service ports, RBAC and storage.
The assistant checks the rendered objects against the CRD schemas that the cluster actually serves. It can also send the changed HelmRelease as a server-side dry-run: the API server tests the change but does not apply it. This dry-run is in development. It runs in observe mode, so it records the result but does not change the proposal. The objects that the chart renders are not sent yet. A dedicated identity sends the request, and an admission policy limits that identity to dry-run only. It can ask, but it can never apply.
The diff is tiny. The MR body carries the reasoning. It says why the assistant chose this version and not the newest. It lists which breaking changes apply and what to do about them. It lists what the assistant could not evaluate, and what to watch after you merge. The full MR is below.
apiVersion: helm.toolkit.fluxcd.io/v2 kind: HelmRelease metadata: name: kube-prometheus-stack namespace: monitoring spec: chart: spec: chart: kube-prometheus-stack version: 61.3.2 sourceRef: { kind: HelmRepository, name: prometheus-community } values: prometheus: prometheusSpec: retention: 15d serviceMonitorSelectorNilUsesHelmValues: false alertmanager: { … 40 lines … }
# quoted from the 67.0.0 release notes "This version upgrades Prometheus to 3.x. Review the Prometheus 3 migration guide before upgrading; some flags and feature flags were removed."
Deployment/monitoring/kube-prometheus-stack-operator - image: quay.io/prometheus-operator/prometheus-operator:v0.75.2 + image: quay.io/prometheus-operator/prometheus-operator:v0.79.2 Prometheus/monitoring/kube-prometheus-stack-prometheus - version: v2.53.1 + version: v2.55.1 CustomResourceDefinition (6) schema updated ServiceMonitor (14) unchanged Service ports · RBAC · PVC templates unchanged
✓ 212 objects schema-valid ✓ server-side dry-run: accepted a real apply by this identity is refused by admission policy
chart: kube-prometheus-stack - version: 61.3.2 + version: 66.7.1
This example is illustrative, but it has exactly the shape of the real thing. The assistant writes these section headings and this target rule today.
gitops-ai/upgrade-kube-prometheus-stack-66.7.1 into main · 1 file · +1 −1This MR upgrades the kube-prometheus-stack chart in monitoring from 61.3.2 to 66.7.1. The newest published version is 72.9.1. This MR stops at 66.7.1 on purpose.
Stopped at 66.7.1 because of a breaking change in 67.0.0 (step_required):
This version upgrades Prometheus to 3.x. Review the Prometheus 3 migration guide before upgrading; some flags and feature flags were removed.
The 63.0.0 selector deprecation matches a key set in this HelmRelease, but 64.0.0 reverts it, so it does not apply to a jump past 64.
To cross 67.0.0, you need the Prometheus 3 checks listed under Next step. A follow-up MR will propose 66.7.1 → 68.x after you merge this one and it is healthy.
Nothing. The assistant fetched 38 of 38 release notes. The render pair and the dry-run completed.
| Version | Class | Applies to this release? |
|---|---|---|
| 62.0.0 | CRD update | Handled by the chart's CRD upgrade job. No action. |
| 63.0.0 | values_incompatibility | Moot: reverted in 64.0.0, never installed. |
| 65.0.0 | dependency major (grafana subchart) | Not applicable: grafana.enabled: false. |
| 67.0.0 | step_required | Hard stop. Outside this MR. |
flux get hr -n monitoring kube-prometheus-stack shows 66.7.1, Ready.PrometheusOperatorRejectedResources alerts in the first 30 minutes.Revert this MR. The CRDs of the chart are backward compatible within this range.
chart:
spec:
chart: kube-prometheus-stack
- version: 61.3.2
+ version: 66.7.1
sourceRef:
kind: HelmRepository
name: prometheus-community
Read the 62–67 release notes again. Confirmed the 63/64 revert pair and the 67 stop. The render diff matches the claimed scope. LGTM.
The same research drives the cases where a bump alone would upgrade nothing, or would break something.
updateStrategy: OnDelete keeps running the old image after a chart bump. The MR says so. It lists the rollout steps for each pod. For Vault, you delete the pod, then unseal it, one pod at a time.