Support version compatibility patterns that consist of multiple compatibility groups #33217
Labels
priority-3-medium
Default priority, "should be done" but isn't prioritised ahead of others
type:feature
Feature (new functionality)
Discussed in #33026
Originally posted by mthalman December 10, 2024
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:
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: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.It is proposed to add
compatibilityPrefix
andcompatibilitySuffix
in addition to the existingcompatibility
. Any combination of these should be allowed.Here's an example of how this could be defined:
The text was updated successfully, but these errors were encountered: