renovate and helm

ugly yaml hacks

SEAN K.H. LIAO

renovate and helm

ugly yaml hacks

renovate

At $work we run renovate to keep our docker images up to date, and for us that also means updating the helm charts to use newer images. We also use "upstream" Helm charts (a decision we're considering walking back on).

Renovate supports helm values files with the structure below, note the parent must be called image. (lifted from docs)

1image:
2  repository: "some-docker/dependency"
3  tag: v1.0.0
4  registry: registry.example.com # optional key, will default to "docker.io"

helm

"upstream" helm charts are all over the place in terms of quality and standards. Thankfully, most people seem to follow the basic template created by helm create.

Unfortunately, Helm has a best practices doc that says different things, in particular flat or nested values. Example of flat:

1imageRepository: "some-docker/dependency"
2imageTag: v1.0.0
3imageRegistry: registry.example.com

So what if your helm chart does this?

options

renovate has a general purpose regex manager module that you could use to match the keys. But that's more config to keep somewhere.

YAML has anchors, and references, and Helm thankfully ignores unused values, so you could instead do:

1app:
2  image:
3    repository: &repo "some-docker/dependency"
4    tag: &t v1.0.0
5    registry: &reg registry.example.com # optional key, will default to "docker.io"
6
7imageRepository: *repo
8imageTag: *t
9imageRegistry: *reg

renovate would recognize the nested structure, and helm would dereference the value when it parses the yaml so it all comes out correct.

I was only midly surprised my coworker agreed to this hack...