e27fe66980 | ||
---|---|---|
.. | ||
__snapshots__ | ||
http.ts | ||
index.spec.ts | ||
index.ts | ||
merge-request.ts | ||
readme.md | ||
schema.ts | ||
types.ts | ||
utils.ts |
readme.md
GitLab
Authentication
You can authenticate Renovate to GitLab, with one of these methods:
Three ways to authenticate, choose one
To start, create either:
- a Personal Access Token for the bot account
- or a Project Access Token if Renovate only needs to check and update one project. We do not recommend Project Access Tokens, as you need to configure Renovate, and the token, for each project
- or a Group Access Token to the group Renovate will be working on
Bot or token must have at least developer role
The bot account, or token, must have at least the Developer role. The developer role allows Renovate to create issues and merge requests.
If you want Renovate to automerge, give appropriate permissions
If you are using automerge, the bot account, or token, must have the appropriate "Allowed to merge" permission on the protected branch of your projects.
If only maintainers are allowed to merge, give Maintainer role
If merging is restricted to Maintainers, the bot account or token must have the Maintainer role.
Setting up Project Access Tokens or Group Access Tokens
If you are using a project access token, or a group access token, GitLab creates an internal bot user for you. This bot user is the one that will be used to create merge requests and issues.
Use the name and email of this bot user to configure Renovate when verifing users using push rules. For group access tokens, an expiration date is required, unlike project access tokens where it is optional.
To keep using the same GitLab-generated bot account you must rotate/refresh the Group Access Token before the token's expiry date.
We refer to personal access tokens, project access tokens and group access tokens as access tokens in the instructions that follow.
Permissions for access tokens on real runs
For real runs, give the access token these scopes:
api
write_repository
read_registry
(only if Renovate needs to access the GitLab Container registry)
Permissions for access tokens on dry runs
For dry runs, give the access token these scopes:
read_api
read_repository
read_registry
(only if Renovate needs to access the GitLab Container registry)
Letting Renovate use your access token
Let Renovate use your access token by doing one of the following:
- Set your access token as a
token
in yourconfig.js
file - Set your access token as an environment variable
RENOVATE_TOKEN
- Set your access token when you run Renovate in the CLI with
--token=
Set platform=gitlab
in your Renovate config file
Remember to set platform=gitlab
somewhere in your Renovate config file.
Setting up Renovate for a Private Gitlab container registry
If you use a private GitLab container registry, you must:
-
Set the
RENOVATE_HOST_RULES
CI variable to[{"matchHost": "${CI_REGISTRY}","username": "${GITLAB_USER_NAME}","password": "${RENOVATE_TOKEN}", "hostType": "docker"}]
.Alternatively, if
detectHostRulesFromEnv
is enabled, you can set the CI variablesDOCKER_REGISTRY_GITLAB_COM_USERNAME=${GITLAB_USER_NAME}
andDOCKER_REGISTRY_GITLAB_COM_PASSWORD=${RENOVATE_TOKEN}
. -
Make sure the user that owns the access token is a member of the corresponding GitLab projects/groups with the right permissions.
-
Make sure the access token has the
read_registry
scope.
You may also use a dedicated Deploy Token instead of using RENOVATE_TOKEN
as the password in the above host rule example.
Get colored output
You may want to set FORCE_COLOR: 3
or TERM: ansi
to the job, in order to get colored output.
GitLab Runner runs the container’s shell in non-interactive mode, so the shell’s TERM
environment variable is set to dumb
.
Features awaiting implementation
- The
automergeStrategy
configuration option has not been implemented for this platform, and all values behave as if the valueauto
was used. Renovate will accept the Merge Request without further configuration, and respect the strategy defined in the Merge Request, and this cannot be overridden yet
Server version dependent features
We use the GitLab version API to fetch the server version.
You can use the experimental feature flag RENOVATE_X_PLATFORM_VERSION
to set a specific server version.
By setting the server version yourself, you save a API call that fetches the server version.
- Use
Draft:
MR prefix instead ofWIP:
prefix sincev13.2.0
- Do not truncate Markdown body to 25K chars since
v13.4.0
- Allow configure reviewers since
v13.9.0
Multiple merge request assignees
Multiple assignees are only available on GitLab Premium and Ultimate tiers. Because of a safeguard in GitLab's API if multiple assignees are set, but not available to the project, only the first assignee will be applied.
Verifying users using push rules
When verifying users using push rules, you must use the name and email of the bot user for gitAuthor
.