Support rolling docker tags (like bitnami use)

[viceice]

What would you like Renovate to be able to do?

Support updating 3.4.6-debian-9-r24 docker tags

• 3.4.6-debian-9-r24 -> 3.4.6-debian-9-r25 (patch)
• 3.4.6-debian-9-r24 -> 3.4.6-debian-10-r1 (major?)
• 3.4.6-debian-9-r24 -> 3.4.7-debian-9-r1 (patch)

https://docs.bitnami.com/tutorials/understand-rolling-tags-containers/

Current workaround is to use allowedVersions regex filter and loose versioning.

ref bitnami/charts#5793

Did you already have any implementation ideas?

[rarkins]

Maybe a new type of versioning is necessary to treat the two halves as separate versions? Or could we do it during extract and essentially extract the same dep twice, with two different extractVersion approaches?

[viceice]

I think this is a more genral version of #4860 4 part versioning

[rarkins]

Would you want to update debian versions independently of bitnami versions though?

e.g. if you're on 3.4.6-debian-9-r2 and there's also 3.4.7-debian-9-r2, 3.4.6-debian-10-r1 and 3.4.6-debian-9-r3 and 3.4.7-debian-10-r1 then which PRs to propose and what type of update are they?

[viceice]

As far as i know:

• -debian-9 and -debian-10 are the base images, bitnami will only provide both versions for a short time, so i would propose this as major update
• -r2, -r26 are the rolling release version, which is incremented on every rebuild and will never be changed again (aka immutable tags, so i think a patch update would be fine for me
• 3.4.6, 3.4.7, 3.5.1 ... -> normal version handling as now, but release version can be lower and /or base image version can be higher

I also updated issue description

[mcritchlow]

@viceice - would you be open to sharing the regex setup you're currently using as a workaround?

Current workaround is to use allowedVersions regex filter and loose versioning.

We're stuck on this issue as well.

[viceice]

No, i didn't got it working properly, so went back to short tags and digest pinning.

[mcritchlow]

Oh well, appreciated nonetheless :) Hopefully this gets in at some point.

[mcritchlow]

After the recent security issues, such as log4j, I thought I might bump this and ask if there might be some consideration for prioritizing this strategy bitnami uses which keeps images patched regularly and explicitly. I also recognize that this rolling tag strategy may be unique to Bitnami's images, so perhaps the value proposition is questionable for maintainers. Though #4860 does seem related, if not completely identical.

[viceice]

https://github.com/visualon/renovate-config/blob/main/shared.json#L110-L115

This is what i successfully use

    {
      "description": "Use custom regex versioning for bitnami images",
      "matchPackagePrefixes": ["gcr.io/bitnami-containers/", "bitnami/"],
      "matchDatasources": ["docker"],
      "versioning": "regex:^(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)(:?-(?<compatibility>.*-r)(?<build>\\d+))?$"
    },

[mcritchlow]

@viceice - wow, that's great. Thanks! I'll give it a shot with some of our projects.

[rarkins]

After #24717 maybe we can introduce the concept of updating compatibility like versions too

[cospeedster]

We've a similar problem with fluentd images. I will share a code snippet if we get it working.

[cospeedster]

This seems to work for us:

{
  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "packageRules": [
    {
      "matchDatasources": ["docker"],
      "matchPackageNames": ["fluent/fluentd"],
      "versioning": "regex:^v?(?<major>\\d+)\\.(?<minor>\\d+)\\.(?<patch>\\d+)((?<compatibility>-.*-?)?(?<build>\\d+\\.\\d+))?$"
    }
  ]
}

[cospeedster]

Isn't this handled by workarounds:bitnamiDockerImageVersioning?