Support version compatibility patterns that consist of multiple compatibility groups

[mthalman]

Tell us more.

The versionCompatibility setting only works for version patterns that consist of a single compatibility group. But there can be cases where multiple compatibility groups are needed. This is discussed in #33016.

I'll illustrate this with an example of Docker tags.

This is a source file with a reference to a Docker tag:

FROM mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-helix-amd64

The dotnet-buildtools/prereqs repo contains images from multiple Linux distros. So the tagging pattern is <distro>-<version>[-<variant>]-<architecture>.

Here's a sample of the tags in the repo:

[
  "debian-11-helix-amd64",
  "debian-12-helix-arm64v8"
]

Using the config below, it will cause Renovate to open a PR to update the source file to reference the debian-12-helix-amd64 tag, which doesn't exist:

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["mcr.microsoft.com/dotnet-buildtools/prereqs"],
      "versionCompatibility": "^(?<compatibility>\\D+)-(?<version>\\d+(\\.\\d+)?).*$",
      "versioning": "docker"
    }
  ]
}

The issue is that the version number in the tag is contained in between the two sections that identify compatibility. What is needed is a way to define a versionCompatibility pattern that defines multiple compatibility sections.

Here's an example of how this could be defined:

"versionCompatibility": "^(?<compatibility>\\D+)-(?<version>\\d+(\\.\\d+)?)(?<compatibility2>.*)$",

A set number of compatibilityX identifiers could be supported which would be incorporated into the matching algorithm.

[rarkins]

Let's simplify the example so that customManagers are not necessary here. This requirement could be reproduced/described with a 1-one Dockerfile FROM statement instead

[mthalman]

Good point. I've made an edit to simplify things.

[rarkins]

I'm wondering if a more readable alternative would be to support compatibilityPrefix, compatibilitySuffix and compatibility. That would allow for 3 different compatibility strings, and I think cover 99%+ of cases

[mthalman]

Yeah, I like that.

[rarkins]

Converted to issue: #33217