How to find Docker tags from registry that match the tag pattern of the source to be updated

[mthalman]

How are you running Renovate?

A Mend.io-hosted app

If you're self-hosting Renovate, tell us which platform (GitHub, GitLab, etc) and which version of Renovate.

No response

Please tell us more about your question or problem

I've been trying to find a way to configure Renovate to handle a scenario where I need the version query of a Docker repository to look for tags that match the pattern of the tag from the source file that needs to be updated.

For example, my source file is a custom XML file containing this line that I want to get updated:

<HelixTargetQueue Include="(Debian.11.Amd64)ubuntu.2204.amd64@mcr.microsoft.com/dotnet-buildtools/prereqs:debian-11-helix-amd64"/>

I want debian-11-helix-amd64 to be updated to debian-12-helix-amd64. But I want this to be generalized to work for any tag prefix name. In other words, I don't want to have to hardcode my regex pattern to be specific to the Linux distribution debian.

This is what I've tried:

"customManagers": [
  {
    "customType": "regex",
    "fileMatch": ["UnitTests.proj"],
    "matchStrings": [
      "mcr.microsoft.com/dotnet-buildtools/prereqs:\\D+-(?<currentValue>\\d+(\\.\\d+)?)(-\\S+)?"
    ],
    "datasourceTemplate": "docker",
    "depNameTemplate": "mcr.microsoft.com/dotnet-buildtools/prereqs",
    "extractVersionTemplate": "^\\D+-(?<version>\\d(\\d)?)-\\S+$"
  }
]

The problem is that Renovate's query of the registry is finding tags belonging to other Linux distributions which do not match the prefix of the text I want to update.

To illustrate, this is a sample of the tags that exist for that Docker repository:

[
  "debian-11-helix-amd64",
  "debian-12-helix-amd64",
  "fedora-41-helix"
]

So Renovate finds the fedora-41-helix, applies the extract version template, and sees that 41 is the largest version so it wants to update my tag to debian-41-helix-amd64, not debian-12-helix-amd64.

I need a way to influence the extract logic dynamically so that it uses the prefix value of the text from the source file. Is there a way I can define the extractVersionTemplate that it can reference a capture group from the matchString or something?

Logs (if relevant)

Logs

Replace this text with your logs, between the starting and ending triple backticks

[rarkins]

Look into versionCompatibility. It's the best way to associate the current tag pattern to other/newer tags and maintain compatibility

[mthalman]

Thanks, that was helpful. I've gotten very close to this working with the following configuration:

{
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["mcr.microsoft.com/dotnet-buildtools/prereqs"],
      "versionCompatibility": "^(?<compatibility>\\D+)-(?<version>\\d+(\\.\\d+)?).*$",
      "versioning": "docker"
    }
  ],
  "customManagers": [
    {
      "customType": "regex",
      "fileMatch": ["UnitTests.proj"],
      "matchStrings": [
        "mcr.microsoft.com/dotnet-buildtools/prereqs:(?<currentValue>\\D+-\\d+(\\.\\d+)?).*"
      ],
      "datasourceTemplate": "docker",
      "depNameTemplate": "mcr.microsoft.com/dotnet-buildtools/prereqs"
    }
  ]
}

So I've defined a compatibility pattern for the text before the version number. But there's one scenario where this doesn't work correctly.

Let's say my repository contains the following tags:

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

That will cause Renovate to still attempt to update my debian-11-helix-amd64 tag to debian-12-helix-amd64 when it should not. It's not taking into account the suffix of the tag now. So really I want to define both the prefix and suffix as part of the compatibility pattern. Is there a way to do that?

[rarkins]

You could hardcode the -amd64 suffix if you know that part won't change. If not then I don't think we have a solution for "split" compatibility

[mthalman]

Ok, can we use this discussion as a feature request for supporting such a scenario? In my case the suffix will be highly variable across the tags so hardcoding it isn't feasible.

[rarkins]

No, but you can start a new "suggest an idea" specifically about what you want. You'd need to have a concrete idea on how it could be configured. Today it's pretty simple with a single capture group for compatibility. I guess we could potentially support compatibility2, compatibility3, etc

[mthalman]

I've opened #33026