Reproducible builds cause undefined image selection

[janpieper]

Describe the bug

Some build tools (e.g. jib) set a static value for the layer/image creation date (e.g. 1970-01-01T00:00:00) to allow reproducible builds. This causes issues when using e.g. the latest update-strategy because the image updater sorts the images by their creation date. In those cases it is undefined what image gets selected as the new image. In theory, the image updater could choose a different image on each run.

To Reproduce

Push two or more images with the same creation date to the registry and use the latest strategy.

Expected behavior

I can currently think of two ways to handle those cases:

1. Log a warning message so you can identify this issue
2. Handle as an error because we cannot guarantee the image updater selects the correct image

It's also important to keep in mind that even if the devs re-configure their build tools to include a current timestamp, the registry will most likely still have images with the static value.

Additional context

• https://reproducible-builds.org
• https://reproducible-builds.org/docs/timestamps/
• https://github.com/GoogleContainerTools/jib/blob/master/docs/faq.md#why-is-my-image-created-48-years-ago

Version

0.11.0

Logs

None

[dennbagas]

Actually this is not a bug. It is mentioned in the ArgoCD Image Updater documentation here: https://argocd-image-updater.readthedocs.io/en/stable/basics/update-strategies/#latest-update-to-the-most-recently-built-image

Fluxcd can update a reproducible build by sorting part of an image tag using regex: https://fluxcd.io/flux/components/image/imagepolicies/#examples. Maybe we can implement something like this in ArgoCD Image Updater? This would be very useful