* feat(manager/dockerfile): extract `apk add` packages from `RUN` instructions As noted in #43711, users pin APK packages in their Dockerfiles and want Renovate to update them, which so far has needed a custom manager[0]. Now that we have the `apk` datasource, we can extract these ourselves, and parse the `RUN` instruction more effectively than a regex can. We can do this by: - extracting `apk add` dependencies when processing a `Dockerfile` - ignoring common flags to `apk` before we extract the dependency names, which wasn't straightforward with a Custom Manager - ignoring i.e. `--virtual .build-deps` - handle example cases from [0] and other usages i.e. with a comment in between lines - ensure that `final` doesn't run against the final `apk` install - removing the docs for how to do this with a Custom Manager, as that complexity is no longer needed - skipping `unspecified-version` and `contains-variable` We inform the user that they will need to override the `registryUrls`, as we already have a default on the `apk` datasource and can't override it in a straightforward means. [0]: https://www.jvt.me/posts/2025/03/24/renovate-regex-dockerfile-apk/ Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io> * fixup! feat(manager/dockerfile): extract `apk add` packages from `RUN` instructions Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io> * fixup! feat(manager/dockerfile): extract `apk add` packages from `RUN` instructions Co-Authored-By: Claude Opus 5 <jamie.tanna+claude-code@mend.io> * fixup! feat(manager/dockerfile): extract `apk add` packages from `RUN` instructions Find the command by name wherever it sits in the tokens, rather than skipping an allowlist of shell keywords and variable assignments, so that a wrapper program like `sudo`, `chroot /mnt` or `timeout 30` is handled too. Co-Authored-By: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io> * fixup! feat(manager/dockerfile): extract `apk add` packages from `RUN` instructions --------- Co-authored-by: Claude Opus 5 <jamie.tanna+claude-code@mend.io>
Datasources
Datasources are used in Renovate primarily to fetch released versions of packages.
Follow the class-based programming style
New datasources must follow the class-based programming style.
Use the java-version datasource as a reference.
Add the datasource to the API in api.ts so that the new datasource is usable.
If you find Unused HTTP mocks errors in the Vitest tests and your mocked URLs are correct, make sure the datasource is correctly registered.
getReleases
The minimum exported interface for a datasource is a function called getReleases that takes a lookup config as input.
The config has:
packageName: the package's full name including scope if present (e.g.@foo/bar)registryUrls: an array of registry URLs to try
getReleases should return an object having:
releases: an array of strings of matched versions. This is the only mandatory fielddeprecationMessage: a string description of the package's deprecation notice, if applicablesourceUrl: a HTTP URL pointing to the source code (for example on GitHub)homepage: a HTTP URL for the package's homepage. Ideally should be empty if the homepage andsourceUrlare the samechangelogUrl: a URL pointing to the package's changelog (could be a Markdown file, for example). If not present then Renovate will search thesourceUrlfor a changelog filetags: an object mapping tag → version, for exampletags: { latest: '3.0.0' }. This is only used by thefollowTagsfunction
getDigest
Datasources that support digests (like Docker digests and Git commit hashes) can export a getDigest function.
The getDigest function has two inputs:
config: the Renovate config for the package being updated, has the same fields asgetReleasesnewValue: the version or value to retrieve the digest for
The getDigest function returns a string output representing the digest value.
If no digest is found, the getDigest function should return null.