Michael Kriese
f64ec3975a
* refactor(datasource): separate registry URLs in cache keys with a colon Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> Co-Authored-By: Claude Sonnet 5.5 <michael.kriese+claude-code@mend.io> * fix(datasource/go): separate the remaining cache key parts with a colon Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> * refactor(datasource): build cache keys with a shared colon-joining helper Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> * refactor: build all cache keys with buildCacheKey Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> * refactor(http): keep GET package cache keys as the bare URL Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> * refactor(cache): extend cache key helper to memory cache keys Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> * refactor(datasource/go): prefix the goproxy cache keys with their purpose Co-Authored-By: Claude Opus 5.5 <michael.kriese+claude-code@mend.io> --------- Co-authored-by: Claude Opus 5.5 <michael.kriese+claude-code@mend.io>
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
Freeedition, this datasource requires at least GitLab 13.3 - If you are on the
Premiumor theUltimateedition, 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.