gitlab.md

GitLab Configuration

Here are some configuration examples for configuring Renovate to run as GitLab pipeline. See self-hosting doc for additional information.

For gitlab.com we recommend to check out the renovate-bot/renovate-runner project. Here we have prepared some pipeline templates to run Renovate on pipeline schedules.

Renovate slim

This sample will configure the Renovate slim image.

Additional project environment:

• RENOVATE_TOKEN: access token for renovate to gitlab api (required)
• GITHUB_COM_TOKEN: suppress github api rate limits (required)
• RENOVATE_EXTRA_FLAGS: pass additional commandline args (optional)

GitLab pipeline

The following pipeline runs Renovate normally on main branch and for self-update it runs in dryRun mode.

image: renovate/renovate:37.172.2

variables:
  LOG_LEVEL: debug

renovate:on-schedule:
  only:
    - schedules
  script:
    - renovate $RENOVATE_EXTRA_FLAGS

renovate:
  except:
    - schedules
  script:
    - renovate --dry-run $RENOVATE_EXTRA_FLAGS

Renovate config

The config.js should be in repo root, because Renovate will load it from current directory by default.

If you want to override the Git author and committer, you need to override with environment variables (see below). This is necessary, because the env is preset by Gitlab and overrides any Git config done by Renovate.

There are hostRule's for the GitLab container registry, python package repository, npm package registry, and composer package registry. These hostRule's are only required if you use the specific registry and Renovate should provide updates from that. GITLAB_REGISTRY_TOKEN is a gitlab variable.

Object.assign(process.env, {
  GIT_AUTHOR_NAME: 'Renovate Bot',
  GIT_AUTHOR_EMAIL: '[email protected]',
  GIT_COMMITTER_NAME: 'Renovate Bot',
  GIT_COMMITTER_EMAIL: '[email protected]',
});

module.exports = {
  endpoint: process.env.CI_API_V4_URL,
  hostRules: [
    {
      matchHost: 'https://registry.example.com',
      username: 'other-user',
      password: process.env.GITLAB_REGISTRY_TOKEN,
    },
    {
      matchHost: process.env.CI_API_V4_URL,
      hostType: 'pypi',
      token: process.env.RENOVATE_TOKEN,
    },
    {
      matchHost: process.env.CI_API_V4_URL,
      hostType: 'npm',
      token: process.env.RENOVATE_TOKEN,
    },
    {
      matchHost: process.env.CI_API_V4_URL,
      hostType: 'packagist',
      token: process.env.RENOVATE_TOKEN,
    },
  ],
  platform: 'gitlab',
  username: 'renovate-bot',
  gitAuthor: 'Renovate Bot <[email protected]>',
  autodiscover: true,
};

Parallel Renovate jobs per project

The default renovate job of renovate-bot/renovate-runner does a single run which discovers all repositories and prepares updates for each repository one after another.

These updates can be speed up by doing the runs once for each project in parallel. This also reduces the risk of the run failing altogether if there are errors with one or more repositories.

This is possible in GitLab using dynamic child pipelines. For this, we need two GitLab pipelines, the usual toplevel .gitlab-ci.yml and a separate templates/.gitlab-ci.yml:

.gitlab-ci.yml

include:
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-slim.gitlab-ci.yml'
    ref: v8.81.6

renovate:
  variables:
    RENOVATE_AUTODISCOVER: 'true'
    RENOVATE_AUTODISCOVER_FILTER: '<group>/**'
  script:
    - renovate --write-discovered-repos=template/renovate-repos.json
    - sed "s~###RENOVATE_REPOS###~$(cat template/renovate-repos.json)~" template/.gitlab-ci.yml > .gitlab-renovate-repos.yml
  artifacts:
    paths:
      - renovate-repos.json
      - .gitlab-renovate-repos.yml

renovate:repos:
  stage: deploy
  needs:
    - renovate
  inherit:
    variables: false
  trigger:
    include:
      - job: renovate
        artifact: .gitlab-renovate-repos.yml

This slightly adjusts the renovate job to fetch and write the list of discovered repositories to template/renovate-repos.json. This file and the template/.gitlab-ci.yml is then used to generate a .gitlab-renovate-repos.yml. Here we use sed but anything else would be equally fine; for sed it's important to use a different delimiter than the common / since the template/renovate-repos.json will contain / characters.

The renovate:repos job uses the generated .gitlab-renovate-repos.yml to trigger a child pipeline. The inherit.variables: false here is essential to ensure all predefined GitLab variables are populated normally in the child pipeline.

template/.gitlab-ci.yml

include:
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-slim.gitlab-ci.yml'
    ref: v8.81.6

variables:
  RENOVATE_ONBOARDING: 'true'

renovate:
  parallel:
    matrix:
      - RENOVATE_EXTRA_FLAGS: ###RENOVATE_REPOS###
  resource_group: $RENOVATE_EXTRA_FLAGS

This is a fairly basic integration of the original renovate job with the most interesting part being the RENOVATE_EXTRA_FLAGS variable used as parallel matrix. Since template/renovate-repos.json contains a JSON array, it can directly be used as YAML list here. The ###RENOVATE_REPOS### is an arbitrary identifier (and valid YAML comment).

The template/.gitlab-ci.yml uses this filename since the Renovate gitlabci-include manager supports only .gitlab-ci.yml by default.

The result:

Example .gitlab-renovate-repos.yml

include:
  - project: 'renovate-bot/renovate-runner'
    file: '/templates/renovate-slim.gitlab-ci.yml'
    ref: v8.81.6

variables:
  RENOVATE_ONBOARDING: 'true'

renovate:
  parallel:
    matrix:
      - RENOVATE_EXTRA_FLAGS: ["<group>/project-foo", "<group>/project-bar", ...]
  resource_group: $RENOVATE_EXTRA_FLAGS

The ref used in both pipelines should be updated to the latest version. Also the templates directory name is arbitrary.