Sebastian Poxhofer
a3d265d45d
* refactor(datasource): stop double-caching releases at the index level 15 datasources set `caching = true`, which makes the registry wrapper in `lib/modules/datasource/index.ts` store every `getReleases` result under `datasource-releases-<id>` for 15 minutes, while their own `cached()` wrapper already stores the same result under `datasource-<id>` with a longer TTL and stale-fallback. Drop `caching` from those 15; the four that rely on the index cache alone (dart-version, flutter-version, maven, pypi) keep it. `caching` is documented as requiring the datasource to return the `isPrivate` flag, and none of these 15 ever set it, so the index layer was caching private results unconditionally. The remaining `cached()` layer honours `cachePrivatePackages` as before. Also fix two cache-key/registry defects found alongside: - `galaxy-collection` declares `registryStrategy = 'hunt'` but keyed its cache on the package name only, so a `null` from the first hunted registry was replayed for the second one. The registry URL is now part of the key, which invalidates existing entries once. - `typst` ignores `config.registryUrl` and always reads its default registry, so it now sets `customRegistrySupport = false`. A configured `registryUrls` for typst is now warned about and ignored instead of being silently dropped. * Merge branch 'main' into secustor/refactor/datasource-remove-index-caching
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.