Add switch to "auto image registry detection mode" instead of manual image-list

[grzegdl]

Current approach of defining image-list is great for many use-cases but can give some issues for usages with ApplicationSets templating and helm chart pattern. It would be great if there was a mode to detect the image registry path same like flux is doing. So instead of setting the image list system would check currently set up registries, i.e. in:

        argocd-image-updater.argoproj.io/helm.image-name: app.image.name
        argocd-image-updater.argoproj.io/helm.image-tag: app.image.tag

or check what's the currently deployed image in ArgoCD.

[jannfis]

Can you please elaborate more on the use-cases this would be intended for?

In fact, we already know which images are actually running for a given Argo CD application. Probably. we could implement something like an all or * value for the image-list annotation, but I think that will have some caveats. For example, you may want to update one image according to semver update strategy (e.g. an off-the-shelf image), and another one to be updated to the latest development build using the latest strategy - both with the same application. In an automatic scenario, I don't see any reasonable way to configure that.

[grzegdl]

Huge thanks for a response! Main use-case is easy and automated work of auto image updater with ArgoCD ApplicationSets (i.e. using a matrix of Git Directory generator with Cluster generator). Right now we have issues that i.e. we need to name our application folders with the same name as images in the registry due to using ApplicationSets templates like that: argocd-image-updater.argoproj.io/image-list: app=gcr.io/GCP_PROJECT/{{path.basename}} It's troublesome as we don't always want to name apps folders the same way as their registry image or we simply might want to deploy the same image under several apps within one Appset. So in a nutshell it's hard to automate bootstrapping of new workloads combining Appsets and Image Updater.

For upgrade strategy we always use:

argocd-image-updater.argoproj.io/app.allow-tags: "regexp:{{metadata.labels.env}}-.+"
argocd-image-updater.argoproj.io/app.update-strategy: latest

but that's something that is defined per each Appset so it doesn't look like an issue to me. Please let me know if this explains the ApplicationSets use-case enough, if not I can of course elaborate.

[svmaris]

Our usecase is roughly the same as @grzegdl. To prevent manually creating Application YAML's for all our deployments, we use an ApplicationSet with the Git generator to create them for us, including the argocd-image-updater annotations.

Currently, this forces us to the "1 application uses 1 image" and "the image name is the same als the application name" pattern, which is not always the case.

With the suggestion of @jannfis part of the problem can be solved, but there's no way of telling argocd-image-updater how to handle multiple containers within the same application, so you can't specify the allow-tags or update-strategy for a specific container.

I was thinking: There already is a way to override the Application spec by adding a .argocd-source.yaml to the repo, but this only handles the source part of the Application spec. Could we somehow extend this to allow Application specific overrides on other parts of the Application spec, like the annotations needed for argocd-image-updater?

[grzegdl]

I see there are global annotations added now - https://github.com/argoproj-labs/argocd-image-updater/pull/338 This is a step forward for those AppSet configs not to grow with the amount of services.

Tiny example how it looks on our end right now:

        argocd-image-updater.argoproj.io/write-back-method: git
        argocd-image-updater.argoproj.io/image-list: app=gcr.io/xyz/{{path.basename}},small=gcr.io/xyz/analysis-worker,big=gcr.io/xyz/analysis-worker,infinite=gcr.io/xyz/analysis-worker
        argocd-image-updater.argoproj.io/app.helm.image-name: app.image.name
        argocd-image-updater.argoproj.io/app.helm.image-tag: app.image.tag
        argocd-image-updater.argoproj.io/app.allow-tags: "regexp:{{metadata.labels.env}}-.+"
        argocd-image-updater.argoproj.io/app.update-strategy: latest
        argocd-image-updater.argoproj.io/small.helm.image-name: small.image.name
        argocd-image-updater.argoproj.io/small.helm.image-tag: small.image.tag
        argocd-image-updater.argoproj.io/small.allow-tags: "regexp:{{metadata.labels.env}}-.+"
        argocd-image-updater.argoproj.io/small.update-strategy: latest
        argocd-image-updater.argoproj.io/big.helm.image-name: big.image.name
        argocd-image-updater.argoproj.io/big.helm.image-tag: big.image.tag
        argocd-image-updater.argoproj.io/big.allow-tags: "regexp:{{metadata.labels.env}}-.+"
        argocd-image-updater.argoproj.io/big.update-strategy: latest
        argocd-image-updater.argoproj.io/infinite.helm.image-name: infinite.image.name
        argocd-image-updater.argoproj.io/infinite.helm.image-tag: infinite.image.tag
        argocd-image-updater.argoproj.io/infinite.allow-tags: "regexp:{{metadata.labels.env}}-.+"
        argocd-image-updater.argoproj.io/infinite.update-strategy: latest`

it rapidly grows with the amount of services we're adding which are reusing same container image. Plus requires helm chart aliases which generate additional friction that are counter productive to what ApplicationSets & Image Updater try to achieve.