How to Keep Software Dependencies Up-to-Date with Renovate

Continuously Updating Dependencies in GitLab Projects


Emmanuel S

3 years ago | 4 min read

It’s always the same story: you begin to write a brand new app, a real feat of engineering, making use of cutting-edge technologies and trendy architecture patterns. Once in production, it’s a great success and everybody rejoices!

But after a while, this once lively application sees fewer and fewer updates as the feature pipeline dwindle. You soon end up with a not-so-up-to-date application with outdated dependencies, but everything is still running fine.

Then, a vulnerability flaw in the software is discovered and exploited by a malevolent party-pooper, and boom! Your application is hacked and soon taken down.

We all know how to prevent this: we need to update our software dependencies continuously but let’s face it: it’s a real chore! Surely there’s something that can be done to improve the situation.

In this article, we will see how to automate software dependencies updates using Renovate.

Introducing Renovate

Renovate is a really nifty program written in Typescript. When running, it will scan multiple Git directories for outdated dependencies. Renovate understands a lot of different software ecosystems and is fully customizable.

Once an outdated dependency is found, Renovate will create a merge/pull request for updating. You can even allow him to auto-merge if you are adventurous.

If you are using GitHub or Azure, you can enable it as an application for all your repositories. There was previously a GitLab bot available but it was taken down due to security flaws.

In the end, if you are using GitLab or any other Git provider, you will need to run Renovate yourself by integrating it in your CICD pipeline.

Let’s see how to set up it with GitLab.

Continuously Updating Dependencies in GitLab Projects

The first thing to understand is that you need to give Renovate access to your repositories through the GitLab API. It means creating for example creating a Personal Access Token or Project Access Tokens if you are a paying customer.

By default, Renovate will try to list every repository accessible with this API token. You can of course filter the repositories. However, Renovate won’t do anything unless there is a configuration file in the target repository. So it’s safe to activate the scan on all your repositories, nothing will change (unless the onboarding feature is activated!)

As we will Renovate from a CICD pipeline, we can run it for every push or every MR and so on. It’s up to you! I think it’s enough to run it on schedule though.

Let’s start by creating a new renovate-bot project in GitLab:

Next, we add a .gitlab-ci.yml file to set up a pipeline with a few environments variables:

- work

- docker:20.10.2-dind

stage: work
image: renovate/renovate:24.28.0-slim
RENOVATE_ONBOARDING_CONFIG: '{"$$schema": "", "extends": ["config:base"] }'
RENOVATE_EXTENDS: "github>whitesource/merge-confidence:beta"
DOCKER_HOST: tcp://docker:2375

Nothing too crazy here, just some default Renover parameters:

  • The onboarding feature is disabled; with onboarding activated, an MR for enabling Renovate will be created for every scanned repository
  • Renovate will start the dependency tools (npm, pip, go mod…) as Docker containers if possible so we add a Docker service

You also need to configure the API as RENOVATE_TOKEN environment variable, set in the CICD Variable settings:

We end the pipeline by invoking the bot on schedule or from the Gitlab GUI and setting up a cache for speeding up the future runs:

- renovate
key: ${CI_COMMIT_REF_SLUG}-renovate
- $CI_PROJECT_DIR/renovate
- schedules
- web

If you need to customize further the bot run, you can create a config.json file at the renovate project root. Here we are filtering discovered projects:

"autodiscoverFilter": "company/apps/**",

Right! Let’s test it.

Enabling Renovate for a Repository

You firsts need to ensure your test project is scanned by the configured Renovate bot in the previous step! It means:

  • The API token used can list this project.
  • This project match any filters configured.

Then in your target project, you create a .gitlab/renovate.json file the following content as an example:

"extends": [
"prHourlyLimit": 0,
"prConcurrentLimit": 0

Here we are simply disabling any limitation on the MR creation rate. We want to have all our updating MR at once. Take a look at the options.

Running the Bot

Let’s go back to our renovate-bot project again. We trigger the pipeline by hand from the Gitlab GUI and soon renovate will begin scanning your repositories. You may then see some updating actions in the job logs:

INFO: PR created (repository=company/apps/utils, branch=renovate/dill-0.x)1153 "pr": 26,1154 "prTitle": "chore(deps): update dependency dill to v0.3.3"

If you go to the specified project you will find a new dependency update MR with useful information like the confidence or adoption rate.

In the end, you only need to merge it if you are confident with the update. Don’t forget you can also activate the auto-merge, for example in the dev branch where you may tolerate minor problems with the libs upgrade.


The purpose of computing is automating chores and we are totally in this approach. Renovate behavior is completely configurable and no change is made against your will. With this solution, you upgrade your apps step by step with no effort, ensuring your software performance and safety.

Originally published here.


Created by

Emmanuel S







Related Articles