Take inspiration from FluxCD and use more CRDs

[malnor]

Having use FluxCD quite a lot both as a operations team for kuberntes and observability and as a developer in a team. Flux has a number of things that are better than ArgoCD. Possbily also the other way around. But when it comes to the service called Argo CD image updater, there are definite pointers to be had from FluxCD.

There are a few major problems I see with Argo CD image updater

1. Separation of concerns. I'm all for trunk based development, but seeing that many teams takes a trip down sides roades before they get there, it needs to be easy for them to setup different approaches for different applications, for example application X use tags with Y pattern to deploy to test and Z pattern to deploy to production, while application P just takes the newest image. This is really not simply done as the current approach is to have the applicationset generate applications (this is an argocd problem with separation of concerns) and then add annotations for them to instruct the argo cd image updater to understand what to do. This is extremely hard to setup in a flexible way. If is more or less, follow this pattern for you ALL your applications and it might work.
2. Logs are not good enough, having the problem for an obvious rest call made to figure tags and getting the information unauthenticated while both the configuration not being super clear on how to setup access and the logs not actually saying if they are reading said secret properly makes it super hard to know where the problem is
3. The docs are not good - it lacks examples and clarity. Configuration for access of 3 different types are not clearly defined, making it more or less impossible to know what you need to setup in order for the registry to be read, for git writebacks to work and so on.

FluxCd has 3 CRDs that are used to handle updating based on when images are updated.

1. ImageRepository - this points to the docker registry that should be searched for new images. It also points out which secret to use for when accessing the docker registry - this is a major benefit compared to argocd
2. ImagePolicies - the pattern of each image to search for
3. ImageUpdateAutomation - how to writeback (FluxCD used only git writebacks last I checked), this includes a reference to what Flux calles GitRepositories (these are used by flux to fetch the manifests = part of an applicaiton). So access model is clear

These three togheter can then be placed in each repo, leading to the teams having to understand that which increase complexity, but on the other hand is also allows flexibility and ability by the teams to own their own process.

[yu-croco]

Hi @malnor , since your opinion is about Argo CD itself, not Helm Chart, so you can discuss more in upstream.
*argo-helm provides Helm Chart for Argoproj but we don't handle the detail for specifications of them.