Manage your dependencies with Renovate & GitLab

Nowadays, applications are built with the help of many dependencies coming mostly from the OpenSource community. This is very useful to reuse existing components and to be more productive in our work. But it brings some maintenance that can become complex when you embed a lot of them (and some languages are quite heavy user of these 😉 : java, javascript for instance). You need to update often to have the latest version or at least the latest minor version fixing the last security vulnerability. In this article, I'll present Renovate, a nice tool to automatically manage the update of your dependencies.

Even if Renovate is quite complete, I found it not that straight forward to configure at the first point. Here are the steps, I've followed

Configure the bot

First, we need to configure Renovate bot to inspect our repositories. It can be hosted within the repository or in a separate one, if you want to monitor several ones.

Here to keep it simple, I'll put everything in a single one and so I'll have a dedicated branch named renovate-bot to host the bot configuration file.

At the root path of the repository, create a file renovate-config.js:

module.exports = {
    platform: 'gitlab',
    endpoint: process.env.CI_API_V4_URL,
    token: process.env.BOT_TOKEN,
    onboarding: false,
    onboardingConfig: {
      extends: ['config:recommended'],
    },
    repositories: [process.env.CI_PROJECT_PATH]
};

Interesting elements here:

• platform to configure on which one your repositories are hosted, here it's gitlab but it also supports others such as github of course.

• endpoint to configure the platform APIs endpoint, here I use the pre-defined variable available in GitLab to use gitlab.com

• token if authentication is needed to access the endpoints

• repositories is the list of projects to monitor with Renovate. It has to be the full path of each project (group/subgroup/.../project). Again, here I use a pre-defined GitLab variable to get my project path

• onboarding is disable here, you can enable it and Renovate will help you configure your repository by creating an issue with configuration to settle

Configure your repository monitoring

Now the bot is configured, we can configure our repository. You can have a dedicated configuration to each repository you want to monitor so that you can adapt the configuration according to each specificity they may have.

Switch to your main branch, and in a .gitlab directory, create a renovate.json file:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": [
    "config:recommended"
  ],
  "bumpVersion": "patch",
  "commitMessagePrefix": "🚧 Renovate:",
  "commitMessageExtra": "from {{{currentVersion}}} to {{{newVersion}}}",
  "labels": ["🤖_renovate"],
  "prHourlyLimit": 0
}

Here we configure:

• bumpVersion to detect the versions to be detected by the bot. patch is the most fine-grained one, all versions will be tracked. Of course, if you want to reduce the number of propositions, you can set it to minor or even major

• commitMessagePrefix to identify easily the commits that have been created by Renovate

• commitMessageExtra to easily identify the version bumped during the commit

• labels to identify issues & merge requests created by Renovate

• prHourlyLimit to define how may merge requests Renovate can create per hour. By default, it's 2. Here, for the demo, I've set it to 0 which means unlimited

You can go much more deeper into the configuration and the available options (per language, per build engine, ...). All are described in the json schema : docs.renovatebot.com/renovate-schema.json

Configure your CI pipeline to run Renovate

Now, we are ready to run the Renovate bot. Let's configure our job in our GitLab-CI pipeline. Switch back to the renovate-bot branch. In your .gitlab-ci.yml file (create it if it doesn't exist), add the job for Renovate:

stages:
  - 🛂_check

🚧_renovate:
  stage: 🛂_check
  image: ghcr.io/renovatebot/renovate:37.373.0
  script:
    - renovate
  rules:
    - if: '$CI_PIPELINE_SOURCE == "schedule"'
  variables:
    RENOVATE_CONFIG_FILE: renovate-config.js

Here we just use the Renovate official Docker image and provide it the path to our previously created config file.

Renovate is designed to be run frequently to keep you informed about your dependencies. Let's configure a scheduled pipeline to run it.

In the Build > Scheduled pipelines entry in GitLab, create a new one

You can easily choose when you want Renovate to run. Don't forget to pick the right branch, the one hosting the renovate-config.js file.

You don't have to wait for the first occurence of the pipeline to try it. Once saved, just clicked on the Run button of your new scheduled pipeline to execute it.

Pipeline assets generated

After a couple of minutes, you will see the results of the bot run.

First, you'll have a new issue in your repository called Dependency Dashboard. This issue is quite useful as it is the summary of the actions Renovate identified during its execution.

This issue contains multiple information:

• Repository configuration problems

• Open issues regarding dependencies to upgrade (with the links to the merge requests)

• All dependencies detected sorted by build manager

Also, Renovate creates Merge Requests for each dependency requiring to be upgraded

Each request contains:

• the upgrades to be done in a summary table

• reminder about the current configuration of Renovate and available possibilities

Some warnings

I've encountered some problems during the experimentation, here are some that you may faced also:

• autodiscover option: this option is available if you want to scan all the repositories you belong to on a platform. This can be useful on a small platform or if you want to manage globally your projects. In my case, it was a really bad idea 😅 as I belong to way too many groups on gitlab.com. It creates a lot of noice for nothing. So use it very carefully !

• branch naming: when starting the experimentation, I've hosted the renovate bot configuration on a branch called renovate. This is not allowed with Renovate as it will create renovate/xxx branches for each upgrade. But cool behavior, Renovate generates an issue in case of misconfiguration

• gitAuthor option: this option is a little tricky to handle on GitLab. I would recommend to not use it and Renovate will use the information from your token to generate issues, merge requests & commits. If you want to override this behavior, you need to follow this pattern otherwise execution will fail: gitAuthor: "Renovate Bot <donotreply-renovatebot@soprasteria.com>". But it will be used for commits, not for MR and issues.

• Do not edit elements created by Renovate otherwise it will be considered as not maintained by it anymore and then won't be updated if necessary.

Conclusion

This article gives a quick overview about Renovate and how easy it is to maintain your dependencies in your projects. This will help you reduce your technical debt and make a good helper to remind you when updates are necessary.

Coupled with a good CICD pipeline, you'll be able to upgrade with reliance your dependencies with a low risk of any regression.

Renovate provides many advanced options according to the build managers you're including in your projects, have a look to the json schema and the documentation to optimize your usage of this nice tool.

Sources are available in my gitlab : https://gitlab.com/yodamad-trash/fun-with-renovate

By the time of this article, Renovate was in version 37.373.0

🗞️ If you like this article, subscribe to the newsletter to receive my next articles 😉