# Upgrade Helm Chart Dependencies

Yes. A Rush agent bumps your chart's subchart versions, runs helm lint, ct lint and helm unittest, bumps the chart version and opens one pull request.

[Run this on Rush](https://cloud.getrush.ai/run/upgrade-chart-dependencies/helm/), in a Project that has your repository.

## What the agent does

In a chart like kube-prometheus-stack in prometheus-community/helm-charts, the dependencies block in Chart.yaml lists five entries: a local crds chart at 0.0.0, kube-state-metrics 8.6.0 and prometheus-node-exporter 4.60.0 from oci://ghcr.io/prometheus-community/charts, grafana 14.0.1 from oci://ghcr.io/grafana-community/helm-charts, and prometheus-windows-exporter as the range 0.12.*. Chart.lock is in .gitignore, so the versions in Chart.yaml are the only record of what was tested. The agent reads each one, looks up the newest release in its OCI registry, and reads the subchart's own changelog or values diff for anything that renames a value kube-prometheus-stack sets.

That last step matters for this chart. values.yaml configures each subchart under its own key (kubeStateMetrics, nodeExporter, grafana, windowsMonitoring) and many templates and unit tests depend on what those subcharts render. The agent changes one dependency at a time, runs helm dependency update charts/kube-prometheus-stack to pull it, and checks that every value the parent passes still exists in the new subchart.

Then it runs the checks the repository's CI runs. helm lint on the chart. ct lint --config .github/linters/ct.yaml, which also runs the chart's ci/lint.sh and helm unittest --strict --file 'unittests/**/*.yaml' as additional commands. The unit tests under unittests/ cover alertmanager, grafana, prometheus, prometheus-operator, exporters and thanos-ruler. ci/lint.sh runs hack/update_crds.sh and fails on any diff, so the agent runs it to show the crds subchart did not drift.

CONTRIBUTING.md asks for a chart version bump on every change, so the agent bumps version in Chart.yaml (92.10.1 at the time of reading): a minor for compatible subchart bumps, a major only when a subchart change forces users to act, in which case it adds a section to UPGRADE.md in the style of the existing From 91.x to 92.x entry. A dependency whose bump fails a check is left at its old version, with the reason.

## Start it with one API call

`POST https://api.prix.dev/o/{org}/sessions`

```json
{
  "agent": "codex",
  "input": "In charts/kube-prometheus-stack only, upgrade each dependency in Chart.yaml to its latest compatible version, one at a time, with helm dependency update. For each, check that every value kube-prometheus-stack sets for that subchart still exists in the new version. Run helm lint, ct lint --config .github/linters/ct.yaml and helm unittest --strict on the chart's unittests. Bump the chart version as CONTRIBUTING.md asks, and add an UPGRADE.md section only if users must change their values. Leave out any upgrade that breaks the build or tests and say why. Open a pull request titled with the [kube-prometheus-stack] prefix, with one line per bump.",
  "resources": [
    {
      "url": "https://github.com/your-org/your-app"
    }
  ]
}
```

1. **Get an API key.** In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
2. **Send the request.** POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
3. **Read what came back.** Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.

## What comes back

The pull request changes charts/kube-prometheus-stack/Chart.yaml (the dependency versions and the chart version) and, when needed, UPGRADE.md and the unit tests a subchart change legitimately moved. Its title carries the [kube-prometheus-stack] prefix CONTRIBUTING.md asks for. The description lists each dependency with its old and new version, the values it checked, and the checks that passed; dependencies it left out are listed with the failing command and output.

A reviewer looks at two things: whether any helm unittest expectation changed (an updated test should match a subchart's documented change, not just the new output), and whether the chart version bump is the right size for what users will see. The transcript at GET /o/{org}/sessions/{id}/messages has every helm and ct command the agent ran.

## Run it on every subchart release

Subcharts in OCI registries release independently. Start a run from your scheduler once a week, or when a registry notification says a new grafana or kube-state-metrics chart is out, by sending the same POST /o/{org}/sessions body. A webhook on the key tells you when the pull request is ready.

Keep one chart per run. A repository with many charts gets one session each, which keeps each pull request inside the review scope its own maintainers own.

## Why run it on Rush?

A Helm dependency bump is cheap to make and expensive to check. Pulling OCI charts, rendering the whole chart, running chart-testing and the full helm unittest suite, and running the CRD sync script is a lot of tooling to keep installed on a laptop. In Rush it all runs in the session's own sandbox, and the output of each command is kept in the transcript.

Renovate already opens version bumps for charts like this one. What a maintainer lacks is the evidence: a pull request that has already run the chart's own lint and unit tests on each bump, checked the values the parent passes, and left out the one that broke, with its reason.

## Frequently asked questions

### Chart.lock is ignored in my repository. Does that matter?

It means Chart.yaml is the only record of the tested versions, so the agent writes exact versions there and leaves ranges such as 0.12.* alone unless you ask. It runs helm dependency update to fetch them but does not commit a lock file the repository ignores.

### Does it need a Kubernetes cluster?

Not for helm lint, ct lint or helm unittest, which render templates without installing them. The repository's CI also installs the chart on kind with the files in ci/; that job runs on the pull request after the agent opens it.

### Will it bump the chart version?

Yes, because CONTRIBUTING.md asks for it on every change. A compatible subchart bump gets a minor version; a change users must act on gets a major and an UPGRADE.md section.

### Can it handle the grafana subchart moving to another registry?

It upgrades within the repository URL Chart.yaml names. A move to a different registry or chart name is a change to propose in the description, not one it makes as part of a version bump.