Ability to create a combined version for groups

[PM-JoakimGustavsson]

Tell us more.

The problem
A problem that my organization has encountered recently is the combination of using Renovate with an SBOM vulnerablity checker. The SBOM vulnerability scanner that we are using, JFrog Xray, tracks reports for each scan by using a combination of branch-name and build number (which it fetches from the CI system). For singleton projects in Renovate this poses no issue, as these branch names are tagged with the version and name of the dependency that is being upgraded. This ensures that there are no name collissions in Xray.

When it comes to groups however all changes get grouped under the same branch-name, regardless of the version that is being upgraded. If my group is called "example" then the branch name will be "renovate/example" regardless of which updates are included. This triggers a naming collission in Xray for different Renovate upgrades.

Solutions we have attempted
At first we tried setting the additionalBranchPrefix parameter to add a version, but this causes groups to not work at all since the individual packages end up in different branches, see the example log below:

2024-04-18 16:02:39.640   INFO: PR created (repository=FK/jenkins-ppfk, branch=renovate/2.1.566/build-images)
2024-04-18 16:02:39.640         "pr": 1160,
2024-04-18 16:02:39.640         "prTitle": "Renovate: Update repo.pensionsmyndigheten.se/pm-docker-local/ppfk-maven-rhel7-openjdk11 Docker tag to v2.1.566"
2024-04-18 16:02:40.247   INFO: Branch created (repository=FK/jenkins-ppfk, branch=renovate/2.1.572/build-images)
2024-04-18 16:02:40.247         "commitSha": "4253aa00a74c2018ba4cea983c132c9768f7cae0"
2024-04-18 16:02:40.519   INFO: PR created (repository=FK/jenkins-ppfk, branch=renovate/2.1.572/build-images)
2024-04-18 16:02:40.519         "pr": 1161,
2024-04-18 16:02:40.519         "prTitle": "Renovate: Update repo.pensionsmyndigheten.se/pm-docker-local/ppfk-maven-rhel7-openjdk8 Docker tag to v2.1.572"
2024-04-18 16:02:41.108   INFO: Branch created (repository=FK/jenkins-ppfk, branch=renovate/2.1.564/build-images)
2024-04-18 16:02:41.108         "commitSha": "0009768a7cb93b9d5468ca109a10f020442fad30"
2024-04-18 16:02:41.385   INFO: PR created (repository=FK/jenkins-ppfk, branch=renovate/2.1.564/build-images)
2024-04-18 16:02:41.385         "pr": 1162,
2024-04-18 16:02:41.386         "prTitle": "Renovate: Update repo.pensionsmyndigheten.se/pm-docker-local/ppfk-maven-rhel8-openjdk11 Docker tag to v2.1.564"
2024-04-18 16:02:41.658   INFO: Branch created (repository=FK/jenkins-ppfk, branch=renovate/1.0.525/build-images)
2024-04-18 16:02:41.658         "commitSha": "5d68bfe6c30fc5089f19a71b2a4fd3071ca32761"

A second attempt was to set the branch name based on a combination of all of the versions in the group. This was attempted by setting the additionalBranchPrefix to {{#each upgrades as |upgrade|}}{{upgrade.newVersion}}{{/each}}. However setting custom loop variables (or using the Handlebars {{this}})) seems to be blocked in Renovate.

Proposed change/solution
I see two potential solutions that would solve this problem.

The ideal, but likely harder to implement, solution would be to offer a template parameter that contails a hash of all of the versions contained in that branch. This would ensure that the branches get a reproducible name (a requirement for the ability to Decline PRs and not have them be re-opened during the next Renovate run due to a different branch name) and that is collission free for different version upgrades.

A simpler workaround might be to allow the user to configure which HandleBars commands that are blocked/allowed rather than use an enforced preset. This could allow the use of the proposed each-loop that we tried.

Workaround that we are using currently
We have turned off branch-pruning in Renovate, as well as instructed the developers to not delete branches after they are merged. This allows Xray to keep a track of the build number, which prevents the collissions, despite the branches having the same name. Turning off branch pruning however results in a lot of extra maintenance.

Another workaround we are considering is to use a database to track build numbers so that they are unique, even if the branch is deleted in the CI system. Instead of relying on the CI system to track the build number based on which branches it has seen, and reset it back to 1 when a branch is deleted, the system would instead fetch the number from a persistent database. This is likely the more stable, and less prone-to-human-errors approach, but would require large changes to the infrastructure instead.

[rarkins]

Do you mean that you can never reuse the same branch name twice?

[PM-JoakimGustavsson]

That is correct, yes.
For singleton builds we have currently solved this by setting
RENOVATE_BRANCH_TOPIC="{{depNameSanitized}}-{{newVersion}}"
This replaces the default behaviour where sometimes the version is set as <major>.x as this would result in collissions as well. We then set RENOVATE_HASHED_BRANCH_LENGTH=15 in order to avoid the names being truncated and losing the version tag. The hash of course then contains the version info "embedded" in it.

It is unfortunately harder for groups.

[rarkins]

So you are accepting of the fact that any change in versions or content of an existing PR results in it being auto closed and a replacement branch/PR created?

[PM-JoakimGustavsson]

Yes, that is not a problem for us.

[rarkins]

Back to your question, I think if we had the concept of an "updatesHash" value which was a unique hash based on the "contents" of a branch, and pre-calculated for every branch, then we could expose that to templating and then you could have your branchTopic set to that.

[PM-JoakimGustavsson]

That sounds like a great solution, yeah :)

[rarkins]

The next step is which fields are essential for "uniqueness".

I would want it to include not just datasource + packageName + from/to versions but also the file names affected, in case those change.