mirror of
https://github.com/renovatebot/renovate.git
synced 2026-10-25 15:01:49 +00:00
Jamie Tanna
2d239d2cc1
* docs: explicitly document `depTypes` each manager supports A long-standing question we receive is "what `depTypes` can I match against in my project". Although the best recommendation we usually have is "check the `packageFiles with updates" log line (as a very key log line for users), we can go one step further and try and create a stronger contract. To do this, I've used Claude Sonnet 4.6 to work through the codebase, determine areas that a `depType` is set in a manager (statically or dynamically) and generate a structured, typed, means to document how they're used. Through a few iterations of the process, and attempts at human-written documentation, we've settled on: - prioritising autogenerated documentation (for humans to read) to note what `depTypes` are known, and what they are - `knownDepTypes`, to describe any known, static, `depType`s and their human-readable meaning - with the `prettyDepType`, if used - `supportsDynamicDepTypesNote`, to add a Markdown note to the generated documentation While here, we also: - make sure to note this in the "adding a new package manager" documentation - remove any hand-written references to `depTypes` in each manager's documentation page - correct the Gleam `depTypes` - make sure to use the `knownDepTypes`'s `prettyDepType` definition if we know it, for a given `depType` The descriptions have been generated by Claude Sonnet, with some human-written tweaks where appropriate. [0]: https://github.com/renovatebot/renovate/discussions/15176 Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io> * fixup! docs: explicitly document `depTypes` each manager supports * docs(manager): display `depTypes` documentation if none present For consistency, and to make it more explicit. --------- Co-authored-by: Claude Sonnet 4.6 <jamie.tanna+claude-code@mend.io>
Extracts Docker dependencies from gitlab-ci.yml files.
If you need to change the versioning format, read the versioning documentation to learn more.
If you use Gitlab Dependency Proxy then you can use these predefined variables as prefixes for your image:
CI_DEPENDENCY_PROXY_GROUP_IMAGE_PREFIXCI_DEPENDENCY_PROXY_DIRECT_GROUP_IMAGE_PREFIX
If you use predefined GitLab CI variables like CI_REGISTRY or CI_SERVER_FQDN make sure to configure their value via registryAliases:
{
"registryAliases": {
"$CI_REGISTRY": "registry.example.com",
"$CI_SERVER_FQDN": "gitlab.example.com",
"$CI_SERVER_HOST": "gitlab.example.com"
}
}