How to stay up to date on your external dependencies with Renovate
An article from Julien BOUFFARD, Android developer at Pepper.
Photo by Markus Spiske on Unsplash
Software developers often rely on external dependencies to build their applications.
As time goes by, these dependencies are updated and it’s important to install these to benefit from security fixes, new features, etc.
Why renovate?
Most of the time, these dependencies are listed with their corresponding version on a configuration file (for example: package.json, composer.json, libs.versions.toml, etc.)
Developers can update the version on these files and install the updated dependency manually. Still, it means searching from time to time for new versions of each dependency and checking in the release note what changed.
Renovate is a npm package that will scan your configuration file(s) in your repositories, check for new versions of your dependencies and create merge/pull requests with the new version update, the release note and some other useful information.
Renovate is multi-platform and multi-language and can use multiple package managers.
It’s still up to the developers to test for any regression caused by the update but you get automatic update MR/PR to keep your application up to date.
A working example on GitLab
Renovate provides a lot of options. It’s usable on Github, GitLab, Bitbucket and so on.
This example can be customized to your needs with a myriad of configuration options.
Hub project
We first need to create a new project on GitLab that’s going to act as a scan hub. You can name it however you like.
It’s now time to fill this empty repository.
First, add a .Gitlab-ci.yml file:
# .GitLab-ci.yml
include:
- remote: "https://GitLab.com/renovate-bot/renovate-runner/-/raw/$RENOVATE_VERSION/templates/renovate.GitLab-ci.yml"
variables:
DOCKER_DRIVER: overlay2
CI_RENOVATE_IMAGE: renovate/renovate:slim
RENOVATE_TOKEN: $ACCESS_TOKEN
RENOVATE_EXTRA_FLAGS: - autodiscover=true - autodiscover-filter=$AUTODISCOVER_FILTER - onboarding=true
LOG_LEVEL: $LOG_LEVEL
renovate:
image: $CI_RENOVATE_IMAGE
rules:
- if: '$CI_PIPELINE_SOURCE == "schedule"'The include remote basically adds a stage that’s going to use a renovate docker image and run a command on it with the options we provide via environment variables.
$RENOVATE_VERSION, $ACCESS_TOKEN, $LOG_LEVEL and $AUTODISCOVER_FILTER are all custom variables added to our project.
The most important ones are $ACCESS_TOKEN and $AUTODISCOVER_FILTER.
Access token is a GitLab access token with read_user, api and write_repository scopes that’s going to be used by Renovate to scan your repositories.
The autodiscover filter will be used to provide the list of repositories renovate should scan. For example: mygroup/*. All repositories inside the mygroup group.
$RENOVATE_EXTRA_FLAGS is passed as a parameter to the docker renovate command.
Optionally, you can add an environment variable name GITHUB_COM_TOKEN in your CI/CD variables with a valid minimum scoped GitHub access token. This will enable Renovate to fetch release notes from GitHub whenever possible. It’s always nice to have at hand.
Next, we add a config.js file:
// config.js
module.exports = {
platform: “GitLab”,
onboarding: true,
baseBranches: [“develop”],
extends: [
“config:base”js
]
}We give renovate a few basic configuration options. Most of them can be moved to each repository instead.
Finally, we schedule GitLab with pipeline schedules to run this pipeline daily, for example.
That’s all. Renovate is ready to scan.
Repository onboarding
Next time GitLab runs the pipeline, Renovate will scan your repositories and create an onboarding MR to configure each repository. Once this MR is merged, Renovate will be able to update your dependencies.
This onboarding MR will list all the detected configuration files, summarize the configuration settings and dependencies updates that are available.
It will also add a renovate.json file in your repository.
// renovate.json
{
“$schema”: “https://docs.renovatebot.com/renovate-schema.json",
“extends”: [
“config:base”
]
}This file with almost no options is the one you can use to configure renovate for each repository's specificities.
Let’s add some options. Many options are available depending on the platform you use (GitLab self-hosted or not, Github, etc.)
It now looks like this:
// renovate.json
{
“$schema”: “https://docs.renovatebot.com/renovate-schema.json",
“enabledManagers”: [“gradle”, “maven”, “npm”],
“labels”: [“update dependencies”],
“dependencyDashboard”: true,
“dependencyDashboardApproval”: true,
“gradle”: {
“fileMatch”: [
“libs\\.versions\\.toml$”
]
},
“extends”: [
“config:base”
]
}Since we are configuring it for an Android application, we add the related dependency managers, the file Renovate should look for to update the version and the text in the label created with the MR.
We also opted for a dependency dashboard. It’s totally optional. It will create an issue in GitLab, listing all the available dependency updates with check boxes and the ones we already updated.
We select the ones Renovate should create an MR for and the next time the pipeline runs, it will create the MRs. With the dependency dashboard, we avoid a flood of MRs in case we have a lot of dependencies to update.
Automatic dependency update
Now that renovate is ready, here’s what an MR looks like:
The only diff that’s going to be committed is the change in .toml file:
desugarJdkLibs = “2.0.2”
is now
desugarJdkLibs = “2.0.3”
Some possible configurations
It’s possible to allow Renovate to auto-merge the dependencies MRs. First Renovate will run your pipeline and wait for your tests to succeed.
You can also configure assignees, labels, update only minor versions of dependencies for example and keep major updates manual.
You can see in the config.js and renovate.json files a key extends with an array of values. These are presets, you can create a custom one, or use predefined ones. They are just predefined sets of options.
For example: automergeStableNonMajor
{
“packageRules”: [
{
“automerge”: true,
“matchCurrentVersion”: “>= 1.0.0”,
“matchUpdateTypes”: [
“minor”,
“patch”
]
}
]
}Conclusion
That’s all that’s needed for a simple automatic dependency follow up to keep your application up to date.
With minimum configuration, your Renovate project hub can scan multiple repositories and read inside each of them the configuration that’s relevant to its need.
You can auto-merge the update dependencies in one repository and have a dashboard with fine control over which dependency update MR we should create in another one.
