A guide to keeping dependencies up-to-date for enhanced security and efficiency in development

Maintaining your project's dependencies felt time-consuming? Having more than ten backend services and a few frontend applications can easily give me something you want to avoid. I think you are already familiar with automated tools like Dependabot and Renovate, as it is a crucial part of a healthy project.

Our context

At CommIT Smart we provide our clients with ready-to-market application services. To keep our partners' infrastructure, backend services, and frontend applications current, we provide this automated solution.

Which tools and coding languages do we use?

• GitLab, GitLab CI
• GoLang, Java, React, Angular, React-native, Terraform, Docker, Kubernetes, Helm
• Renovate

How did we configure Renovate?

The automation of everything we do is done by GitLab Continuous Integration. It was extremely convenient to set up our pipeline with Renovate.

You must first create your own repository. Add the following content to gitlab-ci.yml:

include:
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate.gitlab-ci.yml'

It will take a predefined renovate.gitlab-ci.yml from the renovate-bot/renovate-runner GitLab project. The renovate.gitlab-ci.yml file contains the stages which seek for new versions of your projects.

In order to include your projects you need to define a CI/CD Variable called RENOVATE_EXTRA_FLAGS. Navigate to your Gitlab repository, Open Settings > CI/CD > Variables. Add a new variable.

We added the flag like this: RENOVATE_EXTRA_FLAGS=--autodiscover=true --autodiscover-filter=/commitsmart/.*/

Github.com token for release notes (optional) As renovate’s documentation describes:

If you are running on any platform except github.com, it’s important to also configure the environment variable GITHUB_COM_TOKEN containing a Personal Access Token for github.com. This account can actually be any account on GitHub, and needs only read-only access. It's used when fetching release notes for repositories in order to increase the hourly API limit. It's also OK to configure the same as a host rule instead, if you prefer that.

We created the personal access token, and added a new GITHUB_COM_TOKEN variable inside our newly created renovate runner repository.

GitLab CI Scheduler

The only thing left we need to configure is the CI Scheduler. Navigate to your Gitlab repository, Open CI/CD > Schedules. Create a new scheduler with your preferences. We created the scheduler with a pattern: 0 * * * * . It runs every hour, which is frequently enough to keep our projects fresh.

Finally, the runner has been configured successfully. In order to tell renovate what would be the purpose of a given project, we will need to create the project level configuration.

Add renovate configuration to your application repository

I picked a GoLang based repository. Go projects have go.mod & go.sum. go.mod contains the dependencies and its versions, go. sum contains the expected cryptographic checksums of the content of specific module versions. If you update a version, you also want to run go mod tidy. It will update your go.sum file. Renovate won’t run it automatically, but it provides a solution for doing that.

Create a new file in your project root called renovate.json. We have the following configuration for one of our simplest Go project:

{
    "extends": ["config:base"],
    "labels": ["renovate", "dependencies"],
    "postUpdateOptions": ["gomodTidy", "gomodUpdateImportPaths"],
    "assigneesFromCodeOwners": true,
    "packageRules": [
        {
            "matchUpdateTypes": ["minor", "patch", "pin", "digest"],
            "automerge": true
        }
    ]
}

First of all, it will take config:base to extend the default configuration from. labels tells renovate to add renovate & dependencies tags to the MRs created by the runner. The postUpdateOptions gives endless functions for every kind of projects, here we are able to add gomodTidy & gomodUpdateImportPaths. These will update the dependencies as we want. After creating the MRs, Renovate will assign the MRs to the code owners. It will read the CODEOWNERS file to do so (It means you need to add codeowners file first).

The tricky part is packageRules. The initial purpose was that, we would reduce the time we spend on seeking for new versions, updating, reviewing & merging the MRs. This block of code helps us too. Because of this, Renovate will automatically merge MRs which are about minor, patch, pin, digest version updates. The steps are the following:

• Renovate first run is executing
• Renovate checks new versions & creates MRs
• Assign it one of our code-owners
• Renovate first run is finished
• Meanwhile the MR pipelines are successful
• Renovate second run is executing
• Renovate checks the previously opened MRs
• If auto-merge enabled, it merges the MR
• Renovate checks new versions & creates MRs

What does the MR look like?

We have the Release Notes for the updated package. How does the new version differ from the old one? The file is there. Is auto-merge enabled? You can also find it there. Isn't it awesome?

Summary

• Create a new repository
• Add gitlab-ci.yml with including the renovate-bot template
• Add CI/CD Variables
• Add CI/CD Scheduler
• Add renovate configuration to application projects