Skip to content

Gitlab Tags Datasource

Identifier: gitlab-tags

Default versioning: no default versioning

Custom registry support:

✅ Custom registries are supported.


GitLab Tags API supports looking up Git tags and can be used in combination with regex managers to keep dependencies up-to-date which are not specifically supported by Renovate.

To specify which specific repository should be queried when looking up a package, the packageName should be set to the project path.

As an example, gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list would look for releases in the gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list project.

To specify where to find a self-hosted GitLab instance, specify registryUrl. An example would be

Usage Example

A real-world example for this specific datasource would be maintaining package versions in a config file. This can be achieved by configuring a custom manager in renovate.json for files named versions.ini:

  "customManagers": [
      "customType": "regex",
      "fileMatch": ["^versions.ini$"],
      "matchStrings": [
        "# renovate: datasource=(?<datasource>.*?) depName=(?<depName>.*?)( versioning=(?<versioning>.*?))?( registryUrl=(?<registryUrl>.*?))?\\s.*?_VERSION=(?<currentValue>.*)\\s"
      "versioningTemplate": "{{#if versioning}}{{{versioning}}}{{else}}semver{{/if}}"

Now you may use comments in your versions.ini files to automatically update dependencies, which could look like this:

# renovate: datasource=gitlab-tags depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list versioning=semver registryUrl=

By default, gitlab-tags uses the semver-coerced versioning scheme.

Open items

The below list of features were current when this page was generated on May 26, 2024.

Feature requests

  • datasource gitlab-tags: private repository support #8159