Ability to create a combined version for groups #28523
PM-JoakimGustavsson
started this conversation in
Suggest an Idea
Replies: 2 comments 5 replies
-
Do you mean that you can never reuse the same branch name twice? |
Beta Was this translation helpful? Give feedback.
3 replies
-
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. |
Beta Was this translation helpful? Give feedback.
2 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
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: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.
Beta Was this translation helpful? Give feedback.
All reactions