public/geek-cookbook
1
0
Fork 0
mirror of https://github.com/funkypenguin/geek-cookbook/ synced 2025-12-13 01:36:23 +00:00
Code Issues Releases Wiki Activity

Remove troublesome post

Browse Source 
Signed-off-by: David Young <davidy@funkypenguin.co.nz>
This commit is contained in:
David Young
2023-02-07 18:48:39 +13:00
parent 747290f634
commit 62138ca5fb
1 changed files with 131 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

131
consolidating-renovate-prs.md Normal file
View File

@@ -0,0 +1,131 @@
---
draft: true
date: 2023-02-07
categories:
- note
tags:
- renovate
---
# Consolidating multiple manager changes in Renovate PRs
I work on several large clusters, administered using [FluxCD](/kubernetes/deployment/flux/), which in which we carefully manage the update of Helm releases using Flux's `HelmRelease` CR.
Recently, we've started using [Renovate](https://github.com/renovatebot/renovate) to alert us to pending upgrades, by creating PRs when a helm update _or_ an image update in the associated helm values.yaml is available (*I like to put the upstream chart's values in to the `HelmRelease` so that changes can be tracked in one place*)
The problem is, it's likely that the images in a chart's `values.yaml` **will** be updated when the chart is updated, but I don't need a separate PR for each image! (*imagine a helm chart with 10 image references!*)
The first time I tried this, I ended up with 98 separate PRs, so I made some changes to Renovate to try to "bundle" associated helmrelease / helm values together...
<!-- more -->
## Create a "bait" HelmRelease
Here's the challenge - given only a helm release version number, how do we create a file containing the helmrelease details, **and** the helm value details? Turns out that's relatively easy, since helm is able to retrieve a chart's values with `helm show values`, so I have an ansible playbook which (*per helm-chart*) retrieves these, using `helm show values {{ helm_chart_repo }}/{{ helm_chart_name }} --version {{ helm_chart_version }}`. [^1]
The values are inserted into a helmrelease YAML file using a template like this:
```yaml
{% raw %}
# This file exists simply to trigger renovatebot to alert us to upstream updates, and it's not
# intended to ever be actually processed by flux
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: {{ helm_chart_release }}
namespace: {{ helm_chart_namespace }}
spec:
chart:
spec:
chart: {{ helm_chart_name }}
version: {{ helm_chart_version }}
sourceRef:
kind: HelmRepository
name: {{ helm_chart_repo }}
namespace: flux-system
values:
{% filter indent(width=4) %}
{{ _helm_default_values.stdout }}
{% endfilter %}
{% endraw %}
```
Which results in a helmrelease which looks a bit like this:
```yaml
{% raw %}
# This file exists simply to trigger renovatebot to alert us to upstream updates, and it's not
# intended to ever be actually processed by flux
apiVersion: helm.toolkit.fluxcd.io/v2beta1
kind: HelmRelease
metadata:
name: mongodb
namespace: mongodb
spec:
chart:
spec:
chart: mongodb
version: 13.6.2
sourceRef:
kind: HelmRepository
name: bitnami
namespace: flux-system
values:
## @section Global parameters
## Global Docker image parameters
<snip for readability>
## Bitnami MongoDB(&reg;) image
## ref: https://hub.docker.com/r/bitnami/mongodb/tags/
## @param image.registry MongoDB(&reg;) image registry
## @param image.repository MongoDB(&reg;) image registry
## @param image.tag MongoDB(&reg;) image tag (immutable tags are recommended)
## @param image.digest MongoDB(&reg;) image digest in the way sha256:aa.... Please note this parameter, if set, will override the tag
## @param image.pullPolicy MongoDB(&reg;) image pull policy
## @param image.pullSecrets Specify docker-registry secret names as an array
## @param image.debug Set to true if you would like to see extra information on logs
##
image:
registry: docker.io
repository: bitnami/mongodb
tag: 6.0.3-debian-11-r9
{% endraw %}
```
I save this helmrelease **outside** of my flux-managed folders into a folder called `renovatebait` (*I don't want to actually apply changes immediately, I just want to be told that there are changes available. There will inevitably be some "massaging" of the default values required, but now I know that an update is available.*)
## Alter Renovate's packageFile value
Just pointing renovate at this file would still create multiple PRs, since each renovate "manager" creates its PR branches independently... the secret sauce is changing the **name** of the branch renovate uses for its PRs, like this:
```yaml
{% raw %}
"flux": {
"fileMatch": ["renovatebait/.*"]
},
"helm-values": {
"fileMatch": ["renovatebait/.*"]
},
"branchTopic": "{{{replace 'helmrelease-' '' packageFile}}}",
{% endraw %}
```
The `branchTopic` value takes the `packageFile` name (i.e., `helmrelease-mongodb.yaml`), strips off the `helmrelease-`, and creates a PR branch named `renovate/renovatebait/mongodb.yaml`.
Now next time renovate runs, I get a single, nice succinct PR with a list of all the chart/images changes, like this:
![PR summary screenshot](https://static.funkypenguin.co.nz/2023/Update_docker.iobitnaminginx_Docker_tag_by_funkypenguin-concourse-bot__Pull_Request_1989__gerg-orgkube-cluster_2023-02-07_18-05-07.png)
And an informative diff, like this:
![PR screenshot](https://static.funkypenguin.co.nz/2023/Update_docker.iobitnaminginx_Docker_tag_by_funkypenguin-concourse-bot__Pull_Request_1989__gerg-orgkube-cluster_2023-02-07_18-07-15.png)
## Summary
By changing the name of the PR branch that renovate uses to create its PRs, it's possible to consolidate all the affected changes in a single PR. W00t!
[^1]: Yes, we ansiblize the creation of our helmreleases. It means all versions (*images and charts*) can be captured in one ansible dictionary.
--8<-- "blog-footer.md"