0
0
Fork 0
mirror of https://github.com/renovatebot/renovate.git synced 2025-05-12 23:51:55 +00:00
renovatebot_renovate/lib/modules/datasource/gitlab-packages
RahulGautamSingh bc7d0595d0
feat(config): managerFilePatterns (#34615)
Co-authored-by: Sebastian Poxhofer <secustor@users.noreply.github.com>
Co-authored-by: HonkingGoose <34918129+HonkingGoose@users.noreply.github.com>
Co-authored-by: Michael Kriese <michael.kriese@visualon.de>
Co-authored-by: Rhys Arkins <rhys@arkins.net>
2025-05-04 08:30:24 +00:00
..
__snapshots__ test: migrate to vitest (#34475) 2025-02-26 09:35:54 +00:00
common.ts refactor: lib/modules (#14488) 2022-03-04 09:04:02 +01:00
index.spec.ts test: cleanup (#34785) 2025-03-13 17:52:09 +00:00
index.ts fix: improve coverage (#34667) 2025-03-06 17:05:19 +00:00
readme.md feat(config): managerFilePatterns (#34615) 2025-05-04 08:30:24 +00:00
types.ts refactor: lib/modules (#14488) 2022-03-04 09:04:02 +01:00

GitLab Packages API supports looking up package versions from all types of packages registry supported by GitLab 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 formed with the project path first, then a : and finally the package name.

As an example, gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js would look for the@gitlab-org/nk-js packages in the generic packages repository of 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 https://gitlab.company.com.

If you are using a self-hosted GitLab instance, please note the following requirements:

  • If you are on the Free edition, this datasource requires at least GitLab 13.3
  • If you are on the Premium or the Ultimate edition, this datasource requires at least GitLab 11.8, but GitLab 12.9 or more is recommended if you have a lot of packages with different names in the same project

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",
      "managerFilePatterns": ["/^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-packages depName=gitlab-org/ci-cd/package-stage/feature-testing/new-packages-list:@gitlab-org/nk-js versioning=semver registryUrl=https://gitlab.com
NKJS_VERSION=3.4.0

By default, gitlab-packages uses the docker versioning scheme.