Mend Renovate In-Depth Q&A
This article covers an in-depth Q&A regarding Mend Renovate. Before diving in, please make sure to understand the differences between our Renovate via Remediate and our standalone Renovate products. The differences between the two are outlined in our Standalone Renovate vs Renovate via Remediate documentation.
What configuration takes precedence when using Renovate via Remediate and when using the standalone Renovate?
Renovate via Remediate:
When using Renovate via Remediate, you should not be using a renovate.json file. All Renovate settings should be added to the remediateSettings object in your .whitesource file or in your global repo-config.json file.
Configuration files will be read in the following order (for example, in GitHub):
whitesource-config/whitesource-config/repo-config.json
<github-orgname>/whitesource-config/repo-config.json
<github-orgname>/<repo-name>/.whitesource
<github-orgname>/<repo-name>/renovate.jsonWhile these config files are read/applied in the above order, their order of authority(precedence) is reversed, meaning that a property defined in the renovate.json file will over-ride the same property defined in the .whitesource file will over-ride the same property defined in the <github-orgname>/whitesource-config/repo-config.json which will over-ride that same property in whitesource-config/whitesource-config/repo-config.json
To illustrate this, we’ve provided an example below using the params "addLabels" and "commitMessageExtra" in the files repo-config.json, .whitesource, and renovate.json. We have a simple POM file with known vulnerable versions of: log4j, pmd-java, and zookeeper. The config will look like (for a GitHub example):
=========================================
<github-orgname>/whitesource-config/repo-config.json
{
"remediateSettings": {
"enableRenovate": true,
"packageRules": [
{
"matchPackagePatterns": ["log4j", "pmd", "zookeeper"],
"addLabels": ["myorg-global.repo-config.json"],
"commitMessageExtra": "--GH Org repo-config"
}
],
...
}
=========================================
<github-orgname>/<repo-name>/.whitesource
{
"remediateSettings": {
"enableRenovate": true,
...
"packageRules": [
{
"matchPackagePatterns": ["log4j", "zookeeper"],
"addLabels": ["dotWhitesource"],
"commitMessageExtra": "--dotWhitesource file"
}
],
}
}
=========================================
<github-orgname>/<repo-name>/renovate.json
{
"remediateSettings": {
"enableRenovate": true,
...
"packageRules": [
{
"matchPackagePatterns": ["log4j", "pmd"],
"addLabels": ["renovatedotjson"],
"commitMessageExtra": "--renovatedotjson file"
}
],
}
}
=========================================The config is read in this order: global > .whitesource > renovate.json. The config's order of authority is the opposite: renovate.json wins over .whitesource wins over global. So in this example, the PRs for these will be created in the following order:
PR#2
Title: Update dependency net.sourceforge.pmd:pmd-java --renovatedotjson file
Labels: dotWhitesource, myorg-global.repo-config.json, renovatedotjson
PR#3
Title: Update dependency org.apache.logging.log4j:log4j-core --renovatedotjson file
Labels: myorg-global.repo-config.json, renovatedotjson
PR#4
Title: Update dependency org.apache.zookeeper:zookeeper --dotWhitesource file
Labels: myorg-global.repo-config.json
Standalone Renovate:
When using standalone Renovate, you'll simply use the renovate.json file for all of your Renovate settings. You can use Standalone Renovate with your Mend for Developers (Repo) integration. To do this, you would turn off Renovate via Remediate by changing your .whitesource file config to use "enableRenovate": false. Then, you will run standalone Renovate and configure it with the renovate.json file.
How do we make sure our validate container matches our OnPrem version?
Standalone Renovate's versioning doesn't match Remediate's versioning, as far as numbering is concerned. Our recommendation is to ensure that both are running on the latest versions.
How do we ensure that issues and PRs that are open with a broken config are actually renovated and remediated when a broken config is fixed/updated?
Since there are various ways to “break” your configuration, this isn’t a “one-size-fits-all” solution. Until the repository is scanned again, there will be no changes.
Once you do scan the repository, the relevant PR should update. If you edit a Renovate/Remediate branch directly, the PR will not update automatically, nor will it rebase (even manually). Also, other configurations may come into conflict with the PR automatically updating. A "frozen" status may occur because the config was not corrected in the way the user may think, thus there are no new updates for the PR to reflect. This can also be challenging, as the feedback loop isn't there for the user.
If you have a wider variety of repositories and users, a more straightforward approach would be to add "recreateClosed": true to your config and then instruct users to manually close the PR in question. This tactic is useful for users when they want to know for sure that the actions they are taking are having an effect.
Are there ways to ensure our regex patterns are correct and which regex libraries are valid?
If you're looking for an online regex testing tool that supports capture groups, try Regular Expressions 101. Be aware that backslashes ('\') of the resulting regex have to still be escaped e.g. \n\s --> \\n\\s. You can use the Code Generator in the sidebar and copy the regex in the generated "Alternative syntax" comment into JSON.
The full explanation can be found in our Renovate Custom Manager Support using Regex documentation.
Please Note: the examples in the documentation are typically formatted as a config example followed by an example of a Dockerfile on which it would match. These are all correct examples, but not all of the Dockerfiles include outdated packages. So, even though they match, you won't "see" a result on that Dockerfile because it's already up-to-date. Our suggestion is to find an outdated version of the packages listed in the example Dockerfile and downgrade the example file so that you can see the effects of the config.