Integrating Renovate with GitLab and Docker
Renovate is an essential tool for maintaining up-to-date dependencies in your projects. It automates the process of updating dependencies, reducing the manual work and ensuring your codebase stays secure and up-to-date. In this article, we will delve into how to integrate Renovate with GitLab using a Docker image and GitLab CI pipelines. We will cover configuring Renovate across two separate repositories, setting up scheduled pipelines, and various advanced configurations.
Prerequisites
Before we begin, ensure you have the following:
- Two GitLab repositories: one for Renovate configuration and another for the runner where the pipeline will execute..
- Docker installed and configured on your GitLab runner.
Create a Gitlab user for Renovate
After setting up a Renovate user on GitLab, log in to that account and generate a Personal Access Token (PAT) with the following permissions:
- read_user
- api
- write_repository
These permissions will enable Renovate to access your GitLab account and repositories, open merge requests, and manage dependencies.
Setting up Renovate in Gitlab
Create a Renovate project group
Create two projects within the group
— renovate-config : Project which will contain configuration files that can be shared with all GitLab projects
— renovate-runner: Project which will contain the configuration dedicated to the Renovate container
In the renovate-runner project:
- Add CI/CD variable RENOVATE_TOKEN with the token, we created earlier ( Personal Access Token ).
- Optional: GITHUB_COM_TOKEN – Renovate uses GitHub token to fetch release notes. If you prefer to have the changelog of public repositories as part of the MR details, you can create a personal access token with read-only access and add the token to CI/CD variables.
- Create .gitlab-ci.yml file.
image: renovate/renovate:32.6.12
variables:
RENOVATE_BASE_DIR: $CI_PROJECT_DIR/renovate
RENOVATE_GIT_AUTHOR: Renovate Bot <[email protected]>
RENOVATE_OPTIMIZE_FOR_DISABLED: 'true'
RENOVATE_REPOSITORY_CACHE: 'true'
LOG_LEVEL: debug
cache:
key: ${CI_COMMIT_REF_SLUG}-renovate
paths:
- $CI_PROJECT_DIR/renovate
renovate:
stage: deploy
resource_group: production
only:
- schedules
script:
- renovate $RENOVATE_EXTRA_FLAGS
</[email protected]>
create config.json file
module.exports = {
endpoint: 'https://self-hosted.gitlab/api/v4/',
platform: 'gitlab',
persistRepoData: true,
logLevel: 'debug',
onboardingConfig: {
extends: ['renovate/renovate-config'], // reference to config project that we created
},
autodiscover: true,
};
Default Configuration
In the renovate-config project:
Let’s create default.json file which will be used by config.js
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"packageRules": [
{
"depTypeList": [ "devDependencies", "require-dev" ],
"updateTypes": [ "patch", "minor", "digest"],
"groupName": "devDependencies (non-major)"
}
],
"extends": [
"config:base",
":preserveSemverRanges",
":dependencyDashboard",
":rebaseStalePrs",
":enableVulnerabilityAlertsWithLabel('security')",
"group:recommended"
]
}
Integrate into a Project
With the above configs in place, there are a few steps for a project to integrate with Renovate Bot.
Add renovate user in the project with minimal permissions (Maintener/Developer)
Create a file renovate.json in the project root
{
"$schema": "https://docs.renovatebot.com/renovate-schema.json",
"extends": [
"renovate/renovate-config"
]
}
This file includes the generic config from renovate-config
. You can configure this according to the specificities of your project. Next time when the renovate runner scans, it will create an MR if any dependencies have updates.
Extra Tips
When adopting Renovate, setting it up is only 30% of the journey.
To ensure successful team adoption, it’s crucial to implement smart configuration strategies. For instance, using Merge Request (MR) Groups can help reduce the noise from multiple MRs in a single project by utilizing packageRules. You can also limit the number of concurrent MRs/PRs to avoid overwhelming the team.
Consider scheduling automerge for patch updates on specific days (automergeSchedule
), ensuring the team is available if a rollback is needed. You can delay MRs until a certain number of days after a dependency update has been released (minimumReleaseAge) to ensure stability.
Assigning MRs to specific users or teams (assignees / reviewers) ensures proper code review.
Additionally, you can configure Renovate to update itself, but remember to manage dangling Docker images, as Renovate releases updates frequently. For example, setting up a daily Docker image prune with a crontab can help keep things clean.
If you need to create Regex (you will probably need), then look into the customManagers features.
Good to know:
Once a MR gets “merged” or “deleted”, Renovate won’t recreate it ! Let’s say you want to POC the solution to your team or customer, you will first make sure it works as expected before getting into a live demo. During your tests, you will be creating, merging and closing MR/PR. During your POC, if you want Renovate to reopen the exact same PR/MR, then you will need to rename it.
Conclusion:
Renovate is an incredibly powerful tool that plays a critical role in securing the software supply chain. By automating the process of dependency updates, it allows developers to focus more on what they do best—writing code—rather than getting bogged down in time-consuming maintenance tasks. For employers, the adoption of such modern tools can be a compelling way to attract top talent, demonstrating a commitment to efficiency and a developer-friendly work environment. And for those looking to take their automation efforts even further, implementing tools like semantic-release can add another layer of sophistication by fully automating the versioning and release process based on the changes made to the codebase.