Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support version compatibility patterns that consist of multiple compatibility groups #33217

Open
rarkins opened this issue Dec 20, 2024 Discussed in #33026 · 2 comments
Open
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)

Comments

@rarkins
Copy link
Collaborator

rarkins commented Dec 20, 2024

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:

[
  "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.

It is proposed to add compatibilityPrefix and compatibilitySuffix in addition to the existing compatibility. Any combination of these should be allowed.

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

"versionCompatibility": "^(?<compatibilityPrefix>\\D+)-(?<version>\\d+(\\.\\d+)?)(?<compatibilitySuffix>.*)$",
@rarkins rarkins added type:feature Feature (new functionality) priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others labels Dec 20, 2024
@viceice
Copy link
Member

viceice commented Dec 20, 2024

Workaround: use regex versioning

@mthalman
Copy link

Workaround: use regex versioning

Can you provide an example of how that would work with this example?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
priority-3-medium Default priority, "should be done" but isn't prioritised ahead of others type:feature Feature (new functionality)
Projects
None yet
Development

No branches or pull requests

3 participants