argocd-image-updater icon indicating copy to clipboard operation
argocd-image-updater copied to clipboard

'name' strategy sorts numbers wrong

Open Jonas18175 opened this issue 3 years ago • 2 comments

Describe the bug

I tried for update the 'name' strategy - and it sorts the numbers in wrong. I use the Build Number as Image Tag and the previous Number was 225 - and after changing to name strategy it update the deployment to build number 26.

With strategy latest - all is working fine, but I don't like to use that strategy in case if on the ci pipeline is a replay of a older version is done.

To Reproduce

Expected behavior Deployment of the new build number 226

Additional context Current Annotations:

  annotations:
    argocd-image-updater.argoproj.io/image-list: ssomailapi=registry.int.company.io/my/image
    argocd-image-updater.argoproj.io/ssomailapi.update-strategy: name
    argocd-image-updater.argoproj.io/ssomailapi.ignore-tags: latest, master, latest-dev, latest-staging
    argocd-image-updater.argoproj.io/ssomailapi.allow-tags: "regexp:^.*-devel$"
    argocd-image-updater.argoproj.io/write-back-method: argocd

Version argocd-image-updater:v0.11.0

Logs

Jonas18175 avatar Dec 29 '21 12:12 Jonas18175

The name method performs a lexical sort on strings, not on numbers. So, 26 is after 226 in order when treated as string and sorted in an alphabetical way, because the numeric value is not interpreted at all.

So technically, this does not seem to be a bug. However, I think your use case is valid, but I would also think that modifying the name update strategy to also consider numeric values in addition to the lexical order in the alphabet would be a breaking change.

Maybe a new strategy numeric could be introduced to satisfy your use case. I'm just wondering about edge cases, e.g. numbers in the middle of a tag (e.g. foo-29-bar, foo-130-bar etc).

jannfis avatar Dec 31 '21 09:12 jannfis

Also hitting this. In Flux, the image update custom resource uses a back-reference capture group in the regex, and then has a field, extract that takes the reference name. Seems like maybe an additional annotation for the extract might solve that edge case

wmiller112 avatar Aug 12 '22 18:08 wmiller112