feat(lib/modules/versioning): add Alpine (APK) and Chainguard tags versioning support

[lyoung-confluent]

Changes

Introduces a new versioning API alpine which can parse/compare the versioning schema produced by the Alpine Package Keeper (APK) used by Alpine Linux and Wolfi/Chainguard OS packages (not the OS version itself).

Additionally, it introduces a chainguard versioning API which extends the alpine versioning with support for the unique tags feature used by Chainguard (cgr.dev/...) Docker/OCI images.

Context

If you wish to use RenovateBot to upgrade the version of APKs, you can typically make it work using the semver or regex versioning schemes, but it won't handle more exotic versions correctly. At a high-level, APKs have a primary version (ex: 1.2.3) as well as an "epoch" or "revision" (ex: r1) which is typically incremented each time the package maintainer makes a change that differs from the upstream.

For example, the musl package currently has the version 1.2.5-r9. This means the upstream "tag" of musl will be v1.2.5, however the alpine maintainers have made 9 subsequent additional patches/metadata changes (in this case most recently to patch CVE-2025-26519). There are additional features/complexities supported by the versioning scheme such as release candidates (_rc<num>), proposed versions (_p<num>), and more.

This PR adds lib/modules/versioning/alpine which implements the VersioningApi interface allowing RenovateBot to correctly parse and compare these APK versions. It uses the same test data as the apk CLI, however a few more exotic test cases are commented out as they do not correctly parse/sort right now.

In addition to the alpine versioning API, a chainguard versioning API is introduced which extends the alpine versioning scheme. Chainguard maintains distroless (and low/no CVE) Docker/OCI images for many popular projects/images. As these images have become quite popular we would like to be able to maintain/upgrade the tags via RenovateBot.

While Chainguard creates/updates the standard latest tag for each image which can be used via the existing Docker datasource, typically you want to specify an exact version/tag of an image to deploy/use. Chainguard images are generally versioned/tagged using the version of the core package the image is based on/for, as an example: The cert-manager-webhook image will be tagged directly based on the version (including the revision/epoch) of the cert-manager APK package it contains.

However, because an image contains multiple packages, not just the main package we need an additional version field that will be incremented anytime a dependency like glibc is updated but the package remains on the same version. This is handled by Chainguard’s unique tags feature which adds a (always incrementing) date timestamp when the image was built in the format -%Y%m%d%H%M. So using the cert-manager-webhook image as an example, we could have the following tags:

• 1.14.2-r0-202402261115: The first build of 1.14.2
• 1.14.2-r0-202403060824: A dependency like glibc is updated
• 1.14.2-r1-202403070335: A CVE in cert-manager is identified/patched by Chainguard
• 1.14.2-r1-202403081212: A dependency like busybox is updated

The lib/modules/versioning/chainguard API adds support for parsing/comparing this date suffix, as well as logic to avoid mixing -dev tags (contain busybox and other developer tools) with non -dev tags.

Documentation

• I have updated the documentation, or
• No documentation update is required

How I've tested my work

I have verified these changes via:

• Code inspection only, or
• Newly added/modified unit tests, or
• No unit tests but ran on a real repository, or
• Both unit tests + ran on a real repository

[MindTooth]

Regarding Chainguard, it’s important to preface that the unique tags are only for the commercial offerings (requires an account). Free only usually have latest or latest-dev.

[rarkins]

TODO before merging?

[rarkins]

Is it ok if these remain wrong?

[lyoung-confluent]

In practice these variants are quite rare, I believe they are failing because I didn't implement the suffix comparisons (the TODO line above). How would you prefer I proceed? I could attempt to implement the rarely used versions and get to 100% coverage (might take some time before I can get to this), or I could convert the above TODO to an open issue and work on it as a follow-up

[rarkins]

Ideally this file would include isVersion() and equals() tests