Automatically update dependencies in GitLab projects using Renovate
Chapter I: Importance of Automatic Dependency Updates in a CI/CD Process
Automatic dependency updates are becoming an increasingly important aspect of continuous integration and continuous delivery (CI/CD) processes in software development. Its advantages:
Improved security. Vulnerabilities and bugs in dependencies can become a target for cyber attacks and threaten the integrity of the system. Continuously monitoring and updating dependencies helps minimize security risks.
Performance improvement. New versions of dependencies often include optimizations, performance improvements, and bug fixes. Continuous updates help you leverage these improvements for faster, more efficient development.
Simplified maintenance. Manually updating dependencies can be a time-consuming and costly process. Automatic updates reduce the burden on developers and allow them to focus on more important tasks, such as creating new functionality.
Reduce conflicts and compatibility issues. This is especially useful in large projects with many dependencies.
Support continuous improvement. Continuous dependency updates support the idea of continuously improving the codebase. It helps maintain the relevance of the project and its compliance with modern standards and technologies.
Automatic dependency updates play a critical role in ensuring security, performance, and quality in CI/CD processes. The Renovate project provides a tool to effectively implement this important practice in software development.
By default, Renovate supports a large number of programming languages and frameworks. For most developers, a basic setup is sufficient. Renovate itself determines that *.tf refers to terraform, pyproject.toml and requirements.txt refers to python, package-lock.json refers to Javascript, Chart.yaml and values.yaml refers to helm, docker-compose.yml refers to docker .
What’s important is that Renovatebot has a free license GNU Affero General Public License and it can be used to update dependencies in both commercial and non-commercial projects – unlike dependabot.
Chapter II: Connecting renovatebot to GitLab
Renovatebot can be connected not only to public, but also to private Gitlab projects.
To connect Renovate (https://github.com/renovatebot/renovate) to GitLab, you will need the following steps.
Creating a configuration file in a GitLab repository
At the root of your GitLab repository, create a configuration file for Renovate called renovate.json. renovate.json is a configuration file for managing settings for the Renovate tool, which automatically updates dependencies in a project. Here is an example of a minimal renovate.json file:
{
"extends": ["config:base"]
}
This file tells Renovate to use the base configuration to manage dependency updates.
Since Renovate by default updates major, minor, patch versions, below I show the config for updating only patch versions.
{
"extends": ["config:base"],
"packageRules": [
{
"matchUpdateTypes": ["patch"]
}
]
}
To set up GitLab CI/CD using the Renovate utility, you will need to define the following environment variables:
RENOVATE_TOKEN: This is a token with scope read_user, api, and write_repository that provides access to your repository and allows Renovate to automatically update dependencies.
Integration of Renovate into CI/CD pipeline
In file .gitlab-ci.yml of your project, add a task or step to your pipeline that will run Renovate to update dependencies. This step should use the previously installed Renovate configuration file.
Example .gitlab-ci.yml file with Renovate integration might look like this:
include:
- project: 'renovate-bot/renovate-runner'
file: '/templates/renovate.gitlab-ci.yml'
renovate:
image: ${CI_RENOVATE_IMAGE}
variables:
RENOVATE_EXTRA_FLAGS: '$CI_PROJECT_PATH'
rules:
- if: '$RENOVATE_TOKEN == null || $RENOVATE_TOKEN == ""'
when: never
- if: '$CI_PIPELINE_SOURCE == "schedule"'To set up a schedule for running this task, you can go to the section Pipeline schedules In chapter Pipeline and create a schedule using cron syntax. By default Renovate doesn’t find the repository, so you need to set it in a variable RENOVATE_EXTRA_FLAGS this repository (variable $CI_PROJECT_PATH).
If the variable $RENOVATE_TOKEN equal to null or пустой строкеThat pipeline won’t start.
Chapter III: Viewing Renovate Artifacts
The Renovate utility creates a Dashboard and Merge Request (MR) in your version control system (such as GitHub or GitLab) to update dependencies in your project. Here’s what they usually look like:
Dashboard:
The Dashboard in Renovate is a web-based dashboard in issue that provides visibility and control over the process of updating dependencies in your projects. With it, you can see the status of updates, configure rules, manage updates and track the history of changes.
You can select an update in the dashboard and create an MR by clicking on the create merge request button.
We will see a warning:
To get the changelog it is better to create a Github token and an environment variable GITHUB_COM_TOKEN .
The warning “GitHub token is required for some dependencies” says that access to the GitHub Advisory Database is required. Examples of vulnerability updates in Главе VII: Обновление уязвимостей .
Merge Request
Renovate automatically creates an MR that includes updating the dependency to the new version. It usually looks like this:
In MR you will see changes in your project files due to the dependency update. You can also review the changes provided by Renovate and test them before merging.
Chapter IV: Getting Changelog Information
GITHUB_COM_TOKEN: (Optional) This token with scope repo:public_repo is needed to obtain information about the changelog in the repositories.
After adding GITHUB_COM_TOKEN The Merge Request will look like this:
Chapter V: Advanced settings for Renovate
Additional environment variables:
RENOVATE_BASE_BRANCH: This variable allows you to specify the base branch against which Renovate will determine which dependencies to update. This is usually the main branch, such as “main” or “master”.
RENOVATE_DISABLE: You can set this variable to “true” to temporarily disable Renovate in the project if necessary.
By default, Renovate does not add labels to MRs, but you can add them to make it easier to classify and manage MRs using this config:
{
"extends": ["config:base"],
"labels": ["dependencies"],
"packageRules": [
{
"matchUpdateTypes": ["patch"]
}
]
}Chapter VI: Configuring file types in renovate.json
Configuring kubernetes manifest updates (yaml)
If most of the .yaml files in your repository are Kubernetes, you can add this to your configuration:
{
"extends": [
"config:base"
],
"kubernetes": {
"fileMatch": ["\\.yaml$"]
}
}If instead they are all in the k8s/ directory, you should add this:
{
"extends": [
"config:base"
],
"kubernetes": {
"fileMatch": ["k8s/.+\\.yaml$"]
}
}Configuring Flux manifest updates (yaml)
If most of the .yaml files in your repository are Flux, you can add this to your config:
{
"extends": [
"config:base"
],
"flux": {
"fileMatch": ["\\.yaml$"]
}
}If instead they are all in the flux/ directory, you should add this:
{
"extends": [
"config:base"
],
"flux": {
"fileMatch": ["flux/.+\\.yaml$"]
}
}Chapter VII: Vulnerability Update
To check versions for vulnerabilities, Renovatebot uses the following databases:
More details Here
Below is the config for updating only vulnerabilities without regular updates.
{
"extends": [ "config:base"],
"packageRules": [
{
"enabled": false,
"matchPackagePatterns": ["*"]
}
],
"vulnerabilityAlerts": {
"enabled": true
},
"osvVulnerabilityAlerts": true
}Example Merge Request for closing vulnerabilities:
Chapter VIII: Updating vulnerabilities and patch versions
{
"extends": [ "config:base"],
"packageRules": [
{
"matchUpdateTypes": ["patch"]
}
],
"vulnerabilityAlerts": {
"enabled": true
},
"osvVulnerabilityAlerts": true
}All configurations are presented as minimal for ease of understanding. All configurations can be combined.
