Renovate wrongly captures the compatibility in Bitnami Openresty Images

[mparada-suva]

How are you running Renovate?

Self-hosted Renovate

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

Deployed in a self-hosted Openshift cluster using Renovate Helm-Chart version 39.58.1

Please tell us more about your question or problem

OpenResty releases have 4 levels: X.Y.Z.W Where X.Y.Z is the nginx version and W is the added OpenResty version (ref). The current version is 1.27.1.1.

I believe Bitnami packages these as X.Y.Z-W-<base>-<base-major>-r<revision> in this case: 1.27.1-1-debian-12-r4 I'm not sure about this point since I could not find Bitnami's versioning documentation.
The current Bitnami Workaround captures the OpenResty W part of the version as part of the compatibility.

For 1.27.1-1-debian-12-r4 the regex captures groups as follows:
major: 1
minor: 27
patch: 1
compatibility: 1-debian (!)
build: 12
revision: 4

The compatibility capture is thus incorrect and leads to errors or missing pull requests.

My current workaround is to use versioning: loose but I don't know what will happen if, for instance, another base image is used (like ubuntu).

I also looked through the Renovate docs on regex but noticed the only available capture group would be prerelease which does not make sense here.

Any ideas how best to solve this issue?

Logs (if relevant)

Logs

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

[secustor]

You have to match major, minor and patch as is and build should capture the 1 of -1. The compability for you would be debian-12-r4.

[mparada-suva]

Thank you for your response! If I understood you correctly, by capturing debian-12-r4 as the compatibility we would be pinning those values, right? That would not be ideal for us, since we would like to get a PR if any of the numbers in the version go up.

That is why I am trying to understand the loose versioning. From what I understood from the code:

• the first part X.Y.Z is correctly matched and compared correctly
• the rest ist compared alphabetically but numbers are numerically compared so: 1.1.1-2 < 1.1.1-10 which is correct but 1.1.1-1-ubuntu > 1.1.1-1-debian which is actually undefined (and should not generate a PR)

Did I understand loose versioning correctly?

If yes, then I guess we must somehow guarantee only debian based images are considered, pin the debian image version (by considering debian-12 the compatibility) or maybe ignore one of the parts (the revision?).

[mparada-suva]

We decided to go with loose versioning. Not ideal, but since Bitnami says they only use mini-debian it should not cause us problems.