search

argoproj-labs / argocd-image-updater

Automatic container image update for Argo CD
https://argocd-image-updater.readthedocs.io/en/stable/
Apache License 2.0
1.29k stars 265 forks source link

Question: Why just images? #455

Open djfinnoy opened 2 years ago

djfinnoy commented 2 years ago

This tool will fill an important gap in ArgoCD. It is a gap that most people are probably getting around through manual interventions via UI / CLI, or with CI scripts.

That being said, I can't help but feel that the scope is too narrow to solve the fundamental underlying problem. Why is it argocd-image-updater, and not argocd-application-updater?

The reason I ask this question, is because I feel like spec.source.targetRevision is just as relevant as the container image. Bespoke Kubernetes applications are composed of two fundamental, equally important building blocks; the image, and the manifests. Why should it not be possible to deploy new manifests with the same tool as new containers?

The first counter-argument that comes to mind is that Argo CD follows git, so there should be no need for a tool like this with respect to manifests. The container code, on the other hand, should live in a separate repository. Argo CD can't track two repositories for a single application, therefore, the scope of this tool should be to update the container images.

That's fair. However, consider a multi environment setup (eg. dev / staging / prod) where you are striving toward some sort of smooth automatic promotion strategy. With argocd-image-updater, it should be possible (I've not tried to do this yet) to, for example, automatically roll out pre-release tags in staging, and automatically roll out new versions that are greater or equal to a patch release in prod. This is a challenge that a tool like argocd-image-updater would be well equipped to solve. But would you not like to be able to do the same with the manifests?

In our stack, we run a pre-staging cluster where we use CI to automatically swap the target revision of Applications resources to the latest pull request, just to save developers the hassle of having to perform an extra step (manually changing targetRevision) before their manifest modifications are deployed. It would be much nicer if this could be achieved through a tool like argocd-image-updater, simply by configuring Application annotations.

Any thoughts on this? Would this not be a much more powerful tool if it was geared toward modifying Application resources as a whole, rather than just the container aspect of an Application?

aaaaahaaaaa commented 2 years ago

I agree that spec.source.targetRevision is missing from the scope of the updater. It feels like a very odd inconsistency to have a control mechanism over the image versions but not over the chart versions for example. The documentation often points to examples using targetRevision: HEAD, but that seems obviously not very robust and prone to break.