Open KeithB opened 1 year ago
Hi,
Just to clarify; the wud.tag.include
regex is only there to filter what versions should be considered for comparing to the local version.
Capturing groups will have no effects there (do not expect the first group to be considered as the major version, the 2nd as the minor version, etc).
For "exotic tag naming" (as linuxserver tags are...), your best luck is to deal with the wud.tag.transform
label.
This label will allow you to define an extra function to map weird tag names to something more usable.
Basically, it will allow you to indicate a regex with capture groups and a string template to use the captured values as you want.
Based on you example, here is a basic working proposal:
version: "3"
services:
mariadb:
image: ghcr.io/linuxserver/mariadb:10.11.4-r0-ls109
...
labels:
- 'wud.watch=true'
- 'wud.tag.include=^\d+\.\d+\.\d+-.*$$' # Keep only tags matching the same pattern as 10.11.4-r0-ls109
- 'wud.tag.transform=^(\d+\.\d+\.\d+)-.*$$ => $$1' # Transform to something like 10.11.4 to consider mariadb versions only
In this example, I just strip all the -r0-ls109
part to only be notified when a major/minor/patch of mariadb is available but you can adjust it to achieve the logic you want.
Here is the related documentation
I hope it will help you finding a solution to your problem 😃 .
Thanks for the help - appreciate the time taken.
I had wondered about the transform option - more around the possibility of picking which bits of the exotic tag I considered towards a major.minor.patch version. I suspect that will cause more problems though.
Did you have any thoughts on why the WUD thought 3.0.9.1549-ls180
was an upgrade on 3.0.10.1567-ls197
?
For now I've reverted to the 3.0.10 tag that image offers and relying on the sha hash so not a biggie but seems odd.
And lastly a thank you. WUD has been the prompt to finally get back in to good config management practices on what images are running. Too easy to get things going on the latest tag with a "I'll get back to sorting it properly when it works"...
LinuxServer maintains a version-X.X.X
tag which pins it to the app version, but then references the latest image build on LSCR side.
Example: lscr.io/linuxserver/calibre:version-v7.1.0
The following regex takes care of this format: ^version-v(\d+\.\d+\.\d+)$
(make sure to escape the $
if using as a label in Docker Compose).
More info: https://www.linuxserver.io/blog/docker-tags-so-many-tags-so-little-time#3-version-tag-dynamic.
I think I have a similar issue. It looks like WUD seems to only look at the first digit in the patch version and thinking 9 is larger than 11 (because 9 > 1)
Container running with tag pg14-v0.1.11 can be updated to tag pg14-v0.1.9
(And right now there's a v0.1.13 out, so that should be the correct version alerted on)
My WUD labels are:
labels:
- wud.tag.include=^pg14-v\d+\.\d+\.\d+$$
- wud.link.template=https://github.com/tensorchord/pgvecto.rs/releases/tag/v$${major}.$${minor}.$${patch}
- wud.display.icon=si:postgresql
Which seems to match what you had suggested. Does the \d+ not look at the number as a multi digit number? (I also tried with the parenthesis)
- wud.tag.include=^pg14-v(\d+\.\d+\.\d+)$$
same result. How do I get the regex to look at the whole number?
Wait.. The RegEx isn't working right at all. The link template (which lists major, minor and patch levels) gets converted to:
https://github.com/tensorchord/pgvecto.rs/releases/tag/v14.0.0
So from the tag pg14-v0.1.13
it's looking at the 14 as major, and isn't seeing anything else.
How do we craft a regex to capture the 0.1.13? I had figured ^pg14-v\d+\.\d+\.\d+$$
would be it.
After a bunch of testing and frigging with this, I now seem to have this working:
- wud.tag.include=^pg14-v\d+\.\d+\.\d+$$
- wud.tag.transform=(\d+\.\d+\.\d+)$$ => $$1
@fmartinou I love this project. Just started with it and everything runs until one linuxsever package.
In the project https://github.com/linuxserver/docker-tvheadend/releases only the number after ls part defines the number which would need to be compared. Using the tag transform this works perfectly.
- 'wud.tag.include=^[0-9a-f]{8}-ls\d+$$' # a9c6db8a-ls204
- 'wud.tag.transform=^[0-9a-f]{8}-ls(\d+)$$ => $$1' # Transform from a9c6db8a-ls204 to something like 204 to consider the last number only
- 'wud.link.template=https://github.com/linuxserver/docker-tvheadend/releases/tag/$${raw}'
@fmartinou But then the wud.link.template
is wrong, since there the hex value would still be needed. Is there a possibility to access the initial tag untransformed?
@fmartinou But then the
wud.link.template
is wrong, since there the hex value would still be needed. Is there a possibility to access the initial tag untransformed?
I just make it easy on myself (also helpful if you skipped one or more releases) and in those cases just point the link.template to https://github.com/linuxserver/docker-tvheadend/releases
Hi!
Not a WUD issue specifically but having a few headaches with recommendations for label structure when using Linuxserver images (from GHCR in this instance though I believe they keep it consistent across registries). I had a rummage through previous issues and the HA forum thread but couldn't see anything that might help so apologies if this is in the wrong place...
First one is that Linuxserver images seem to all trigger the pre-release semver tagging - their release versioning essentially being-. For example - 10.11.4-r0-ls110 for MariaDB. I've tried a couple of different regexes to try and limit what WUD considers as parts of the version but no luck. Currently using the regex below to try and force it to treat the Linuxserver base as part of the patch level:
The other, that might be linked, was it identifying a minor version downgrade (3.0.10.1567-ls197 down to 3.0.9.1549-ls180) instead of an update to 3.0.10.1567-ls203 from this regex:
^([0-9]\d*)\.([0-9]\d*)\.([0-9]\d*).([0-9]\d*)-ls([0-9]\d*)$$
I do have a few other questions and thought on a possible enhancement but will keep this topic limited to the regex headache for Linuxserver images.
Thanks!