Describe the bug
I was configuring annotations for a helm app in Argo (via the argo-cd helm chart values) and forgot to specify the helm image tag/name paths, so it populated image.tag and image.name instead of my.custom.path.

I added the correct name/tag paths for the images but image.name and image.tag parameter overrides still exist in the rendered application manifest.

To Reproduce
Steps to reproduce the behavior:

Add the following annotations to the Application and let the controller update it:

argocd-image-updater.argoproj.io/image-list: backend=some.repo/backend frontend=some.repo/frontend
argocd-image-updater.argoproj.io/backend.update-strategy: latest

Now go back to the Application and update the annotations to use the correct helm paths:

argocd-image-updater.argoproj.io/backend.helm.image-name: backend.image.repository
argocd-image-updater.argoproj.io/backend.helm.image-tag: backend.image.tag
argocd-image-updater.argoproj.io/backend.allow-tags: regexp:^dev-.*$

My application manifest still shows both parameter overrides:

  helm:
    parameters:
      - name: image.name
        value: some.repo/backend
        forceString: true
      - name: image.tag
        value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
        forceString: true
      - name: backend.image.repository
        value: some.repo/backend
        forceString: true
      - name: backend.image.tag
        value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
        forceString: true

Expected behavior
I would expect to only see:

  helm:
    parameters:
      - name: backend.image.repository
        value: some.repo/backend
        forceString: true
      - name: backend.image.tag
        value: dev-94fc3a6c73367f950935ac0e872e2d31de02f110
        forceString: true

Version
v0.8.0+961de70

Describe the bug
As described in #75, the image updater will perform one application update call for the same application if multiple images are specified for update. This leads to potentially multiple syncs in Argo CD, if auto sync is enabled.

To Reproduce
Specify multiple images for update for an application that has auto sync enabled, and see that the application gets synced more than one time if more than one image has update candidates.

Expected behavior
The application should only sync once, when all image updates have been processed.

Is your feature request related to a problem? Please describe.
ArgoCD supports a concept of Plugins, such as the kustomize/helm integration, and also used for extending ArgoCD for other use cases.

It appears that the argocd-image-updater only functions with the app.Status.SourceType is set to Kustomize or Helm (via auto-detect), and not when it is set to Plugin.

Describe the solution you'd like
When the type Plugin is used, we could still implement Helm or Kustomize like-behavior for git-based workflows, whereas the image override file can be written back to git as if it were one of these two types.

Describe alternatives you've considered
Mainly it would be dropping the use of the plugin, but it has proven to be handy at times for pre-Sync instrumentation of service discovery.

Additional context
Relevant segment using the kustomized helm example:

resources:
  - health:
      status: Healthy
    kind: Service
    name: kustomize-release-name-helm-guestbook
    namespace: default
    status: Synced
    version: v1
  - group: apps
    health:
      status: Healthy
    kind: Deployment
    name: kustomize-release-name-helm-guestbook
    namespace: default
    status: Synced
    version: v1
  sourceType: Plugin
  summary:
    images:
    - gcr.io/heptio-images/ks-guestbook-demo:0.2

I'm not 100% sure if this is an ArgoCD thing, argocd-image-updater, or sort of both for a feature such as this. I understand there's a lot of "if" there especially if it couldn't reconcile using the imperative updated to the Application resource itself.

Describe the bug
The a-i-u does not seem to pick up the registry configuration I am providing. There are no logs to this effect at all.

To Reproduce
Configmap argocd-image-updater-config with

data:
  argocd.grpc_web: "false"
  argocd.insecure: "true"
  argocd.loglevel: debug
  argocd.plaintext: "false"
  argocd.server_addr: argocd-server.argocd
  registries.conf: |
    registries:
    - api_url: https://example.com/prefix
      ping: false
      credentials: something
      prefix: xxxx

Expected behavior
According to the relevant code (https://github.com/argoproj-labs/argocd-image-updater/blob/master/cmd/main.go#L174) I would expect a log line about the registries configuration, either a failure or a success report. But apparently cfg.RegistriesConf != "" (L184) is evaluating to false.

Additional context

The registry configuration is correctly mounted in the container

cat app/config/registries.conf
registries:
- api_url: https://example.com/prefix
  ping: false
  credentials: something
  prefix: xxxx

Version
v0.4.0-master

Logs
Startup logs:

time="2020-08-12T12:49:00Z" level=info msg="argocd-image-updater v0.4.0-master starting [loglevel:INFO, interval:2m0s, healthport:8080]"
time="2020-08-12T12:49:00Z" level=info msg="ArgoCD configuration: [server=argocd-server.argocd, auth_token=true, insecure=true, grpc_web=false, plaintext=false]"
time="2020-08-12T12:49:00Z" level=info msg="Starting health probe server TCP port=8080"
[EOF]

Is your feature request related to a problem? Please describe.
It looks like there is a lack of support for getting the API token required to authenticate against the ECR API. It would be great to be able to make use of the IAM Instance Profile assigned to a node which has GetAuthorizationToken permissions. It might look similar to this: https://github.com/awslabs/amazon-ecr-credential-helper/blob/master/ecr-login/api/client.go.

Describe the solution you'd like
The image updater supports ECR authentication

Describe alternatives you've considered
There do not seem to be any alternatives without code changes.

I have deployed an application in Argocd which uses image present in Docker hub container registry, when we update the image with new version in Docker Container Registry, Argocd Image updater should poll the Docker hub Container registry and update the application with latest verison of the image. This feature is not working.

Connection has been established between Argocd and Argocd Image updater, I can see in pod logs of Argocd Image updater,
Starting image update cycle, considering 1 annotated application(s) for update"
time="2020-11-17T09:16:05Z" level=info msg="Processing results: applications=1 images_considered=0 images_skipped=1 images_updated=0 errors=0"

I can see in logs its considering the application for update, but image is getting skipped, can't see any error logs and image is not getting updated for the application.

Logs:

time="2020-11-18T08:01:35Z" level=info msg="Starting health probe server TCP port=8080"
time="2020-11-18T08:01:35Z" level=info msg="Warming up image cache"
time="2020-11-18T08:01:35Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2020-11-18T08:01:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:01:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:03:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:03:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:05:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:05:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:07:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:07:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"
time="2020-11-18T08:09:35Z" level=info msg="Starting image update cycle, considering 2 annotated application(s) for update"
time="2020-11-18T08:09:35Z" level=info msg="Processing results: applications=2 images_considered=0 images_skipped=2 images_updated=0 errors=0"

Registry.config looks like,
accounts.image-updater: apiKey
argocd.grpc_web: "true"
argocd.insecure: "true"
argocd.server_addr: 100.100.100.100
registries.conf: |
registries:
- name: Docker Hub
api_url: https://argocdhub.docker.io
ping: yes
credentials: secret:argocd-image-updater/secrets
defaultns: library

Any help/leads would be highly appreciated.

@jannfis , Could you please help with some leads on this.

Many Thanks!

Describe the bug

The write-back feature works only if the branch is explicitly specified in application source revision. Otherwise it tries to commit to HEAD which does not work.

To Reproduce

Configure writeback for an Argo CD app with empty targetRevision. See error in image updater logs

Expected behavior

Image updater should detect default branch of origin and use it

Is your feature request related to a problem? Please describe.

Currently, applications are checked sequentially for whether there are images to be updated. This can take some serious time, if there are more than a couple of applications and images involved in the process.

Describe the solution you'd like

Applications should be checked & updated concurrently, up to a configurable number of maximum parallelism. This will speed up the process.

Describe the bug
When specifying multiple images to update via the annotation with two of those images as the same docker image but for different containers in your k8s deployment. Image Updater seems to update only one instance of the image.

It does not seem to update the second alias.

To Reproduce
Using this feature here, create an application with two image to update.

Here is my example from our own Django helm chart:

argocd-image-updater.argoproj.io/image-list: asfalia=gcr.io/sopost-k8s/asfalia:~v0.1.0-0, celery=gcr.io/sopost-k8s/asfalia:~v0.1.0-0
argocd-image-updater.argoproj.io/asfalia.update-strategy: latest
argocd-image-updater.argoproj.io/asfalia.helm.image-name: image.repository
argocd-image-updater.argoproj.io/asfalia.helm.image-tag: image.tag
argocd-image-updater.argoproj.io/celery.update-strategy: latest
argocd-image-updater.argoproj.io/celery.helm.image-name: celery.image.repository
argocd-image-updater.argoproj.io/celery.helm.image-tag: celery.image.tag

What i find is the container (aso alias) asfalia does get updated. But the celery container / alias does not.

Here are my helm values input for reference:

image:
  repository: gcr.io/sopost-k8s/asfalia
  tag: ""
  pullPolicy: Always
celery:
  # When enabled, ensure all values are as expected
  enabled: false
  image:
    repository: gcr.io/sopost-k8s/asfalia
    tag: ""
    pullPolicy: IfNotPresent

Expected behavior

Both containers should be updated at the same time when a new image is pushed to the docker registry.

Additional context

Here are some logs showing that the image-updater is aware of the image but only seems to update one of the containers.

time="2020-08-27T09:59:05Z" level=info msg="Successfully updated image 'gcr.io/sopost-k8s/asfalia:v0.1.0-e46d4ba4a7ff398a387b28722332bb821cbf7129' to 'gcr.io/sopost-k8s/asfalia:v0.1.0-b5941f2ec8cb05590f1160bbae1a7ab25f943381'" application=ops-eu-asfalia image_name=sopost-k8s/asfalia image_tag=v0.1.0-e46d4ba4a7ff398a387b28722332bb821cbf7129 registry=gcr.io
time="2020-08-27T09:59:05Z" level=info msg="Processing results: applications=2 images_considered=3 images_updated=1 errors=0"

It would be helpful if in the log output, it showed the alias name too, so you know from the log which container would have been updated.

Version
v0.4.0

Logs

See above.
Also some images in the UI showing only the main image / tag was overridden:

celery is not updated.

asfalia is updated

Describe the bug
When connecting to the registry the argo-image-updater is not authenticating against the server for the access token. Therefore when getting the new image the sever thinks the request is unauthorized and therefore cannot update the images.

Additional context
Tested using docker login with the credentials used for the k8s cluster and had no issues.
Also validated that the associated .dockerconfigjson was able to login and pull images from the same registry with no issues.
Have argocd and argocd-image-updater running in the cluster with the main dev repo, see attached config map for the argocd-image-updater-config

apiVersion: v1
kind: ConfigMap
metadata:
labels:
app.kubernetes.io/name: argocd-image-updater-config
app.kubernetes.io/part-of: argocd-image-updater
name: argocd-image-updater-config
data:
argo.server_addr: "argocd-server.argocd.svc.cluster.local"
argocd.grpc_web: "true"
argocd.insecure: "true"
argocd.plaintext: "false"
registries.conf: |
registries:
- name: my-registry
api_url: https://<registry_name>
ping: yes
prefix: <registry_name>
credentials: pullsecret:argocd-image-updater/regcred

Version
Image: argoprojlabs/argocd-image-updater:latest

Logs
level=error msg="Could not get tags from registry: Get "https://<private_registry>/v2/library/<image_name>/tags/list": http: non-successful response (status=401 body="{\"errors\":[{\"code\":\"UNAUTHORIZED\",\"message\":\"authentication required\",\"detail\":[{\"Type\":\"repository\",\"Class\":\"\",\"Name\":\"library/<image_name>\",\"Action\":\"pull\"}]}]}\n")" alias=backend application=<argo_app>image_name=<image_name> image_tag=<image_tag> registry=<private_registry>
time="2020-09-22T18:51:20Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=1"

Is your feature request related to a problem? Please describe.

Retrieving image tag meta data is an expensive task, depending on the latency of the registry's API. This can lead to a rather long cycle for the first update run, before the image cache is populated, confusing the interval setting.

Describe the solution you'd like

The image cache (which stores the meta data for tags) should be pre-filled before the first update cycle start, and also provide user feedback in the logs about the progress.

Is your feature request related to a problem? Please describe.
GitHub has a new registry ghcr.io, which is currently in beta. We should support it by out of the box, as we already support the docker.pkg.github.com registry.

Describe the bug
With default configuration, metrics and heath can be accessed from both ports.

To Reproduce
Steps to reproduce the behavior:

1. Start it with any parameters.
2. check the output shows a message like this:

   INFO[0000] Starting health probe server TCP port=8080   
   INFO[0000] Starting metrics server on TCP port=8081     
   

3. run curl localhost:8080/metrics, curl localhost:8081/metrics, curl localhost:8080/healthz and curl localhost:8081/healthz to see that all of them worked.

Expected behavior
curl localhost:8080/metrics and curl localhost:8081/healthz should fail.

Additional context

Version
0.8.0

Logs

Is your feature request related to a problem? Please describe.
When connecting to a custom or self-hosted registry, the user should have the option to configure skipping TLS verification for this connection.

Describe the solution you'd like
A new option for the registry configuration that skips TLS verification, i.e. insecure: <true|false>

Is your feature request related to a problem? Please describe.

Currently, image pull secrets can only be specified on a per-registry basis. That means you'd need one credential that has access to all images from this registry, which might not be possible in some scenarios.

Describe the solution you'd like

It should be possible to define Image pull secrets on a per image (or per repository) basis, using an annotation on the application resource. Depending on further design decisions (like, access to remote clusters), it could also be viable to use the imagePullSecret property of existing workloads to figure out what pull secret to use.

I have a project with a newly published image. I can see the argo-image-updater registering the new arrival, and triggering an update. The update does not however go through.
Manually changing the app manifest in Argo does translate through to k8s though. So the connections

Argo-image-updater -> Repository and
Argo -> k8s

do work, it seems to be a problem with the connection

Argo-image-updater -> Argo.

Debug steps
I tried updating manually (editing the live manifest in the Argo UI), that went swimmingly (all pods deployed correctly).
I tried assigning full admin privileges to the argo-image-updater user in Argo, that did not change anything.
I restarted all pods in various configurations.

Logs

oc logs argocd-image-updater-<HASH>

time="2020-09-03T11:32:00Z" level=info msg="Processing results: applications=1 images_considered=1 images_updated=1 errors=0"
time="2020-09-03T11:34:00Z" level=debug msg="Starting image update process"
time="2020-09-03T11:34:00Z" level=debug msg="Considering 1 applications with annotations for update"
time="2020-09-03T11:34:00Z" level=debug msg="Processing application $APPLICATION"
time="2020-09-03T11:34:00Z" level=debug msg="Considering this image for update" application=$IMAGE image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="Using version constraint '>=2.1.0-0' when looking for a new tag" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="found 9 from 9 tags eligible for consideration" image="$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.6"
time="2020-09-03T11:34:00Z" level=info msg="Upgrading image to $REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.102" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:00Z" level=debug msg="target parameters: image-spec= image-name=, image-tag=" application=$APPLICATION image=$REGISTRY/$REPOSITORY/$IMAGE
time="2020-09-03T11:34:02Z" level=info msg="Successfully updated image '$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.6' to '$REGISTRY/$REPOSITORY/$IMAGE:2.1.0-dev.102'" application=$APPLICATION image_name=$REPOSITORY/$IMAGE image_tag=2.1.0-dev.6 registry=$REGISTRY
time="2020-09-03T11:34:02Z" level=info msg="Processing results: applications=1 images_considered=1 images_updated=1 errors=0"

I believe the following of those lines hints at a problem:
time="2020-09-03T11:34:00Z" level=debug msg="target parameters: image-spec= image-name=, image-tag=" application=$APPLICATION image=$REGISTRY/$REPOSITORY/$IMAGE

oc logs argocd-server-<HASH>

time="2020-09-03T11:48:14Z" level=info msg="received unary call /application.ApplicationService/UpdateSpec" grpc.method=UpdateSpec grpc.request.claims="{\"iat\":1597138354,\"iss\":\"argocd\",\"jti\":\"image-updater\",\"nbf\":1597138354,\"sub\":\"image-updater\"}" grpc.request.content="name:\"$APPLICATIONt\" spec:<source:<repoURL:\"$HELM_SOURCE_ENDS_IN_.git\" path:\"$HELM_CHART\" targetRevision:\"HEAD\" helm:<releaseName:\"\" values:\"\" > chart:\"\" > destination:<server:\"https://kubernetes.default.svc\" namespace:\"$APPLICATION\" > project:\"$ARGO_PROJECT\" syncPolicy:<automated:<prune:false selfHeal:false > > > " grpc.service=application.ApplicationService grpc.start_time="2020-09-03T11:48:14Z" span.kind=server system=grpc
time="2020-09-03T11:48:15Z" level=info msg="image-updater updated application spec" application= $APPLICATIONdest-namespace=$APPLICATION dest-server="https://kubernetes.default.svc" reason=ResourceUpdated type=Normal
time="2020-09-03T11:48:15Z" level=info msg="finished unary call with code OK" grpc.code=OK grpc.method=UpdateSpec grpc.service=application.ApplicationService grpc.start_time="2020-09-03T11:48:14Z" grpc.time_ms=1171.407 span.kind=server system=grpc

Any ideas?

Describe the bug
The git push fails if application source file is created by the image updater:

INFO[0003] git commit -a -m Update to new image versions  dir=/var/folders/22/8kj96x2x5q735wjmcsjwb4lh0000gn/T/git-guestbook473645597 execID=xeAwD
ERRO[0003] `git commit -a -m Update to new image versions` failed exit status 1  execID=xeAwD
ERRO[0003] On branch image-updater
Your branch is up to date with 'origin/image-updater'.

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        kustomize-guestbook/.argocd-source-guestbook.yaml

nothing added to commit but untracked files present (use "git add" to track) 
ERRO[0003] Could not update application spec: `git commit -a -m Update to new image versions` failed exit status 1  application=guestbook

To Reproduce

1. Fork https://github.com/argoproj/argocd-example-apps
2. Create application using kustomize-guestbook, downgrade image tag and configure write back
3. Writeback fails

Expected behavior
Image should be successfully updated

Is your feature request related to a problem? Please describe.

Currently, when multiple applications are referencing the same image, the available tags will be gathered from the container registry for each application that is referencing it. This results in unnecessary requests to the registries.

Describe the solution you'd like

We should implement a short living cache that stores available tags for each given image, so that further checks can just reuse that information. The cache should be dumped after each update check cycle.

I can't figure it out the reason of this error .

Steps I followed:
1.- export AWS_ECR_PULLSECRET="AWS:eyJwYXlsb2FkIjoiKzkzVWR0blloSW5zdWFrS0I3UXFXcFV6UDU2eDJJem9HaVh0eWN0UWl1YzZwMnQ2OWJvaWJSM3dFMasdpU"

2.- argocd-image-updater test XXXXXXXX.dkr.ecr.us-east-1.amazonaws.com/k8s/ingress-nginx --update-strategy latest --credentials env:AWS_ECR_PULLSECRET

Result:

INFO[0000] getting image image_name=k8s/ingress-nginx registry=XXXXX.dkr.ecr.us-east-1.amazonaws.com
FATA[0000] could not get registry endpoint: no registry with prefix 'XXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com' configured

any ideas about how to fix it ?

thanks

Describe the bug

When specifying the env var ARGOCD_SERVER either via configmap or in the deployment directly, it does not actually perform an fqdn lookup for the correct IP address and uses the internal cluster service IP instead.

e.x.:

apiVersion: apps/v1
kind: Deployment
metadata:
  labels:
    app.kubernetes.io/component: controller
    app.kubernetes.io/name: argocd-image-updater
    app.kubernetes.io/part-of: argocd-image-updater
  name: argocd-image-updater
spec:
  revisionHistoryLimit: 0
  selector:
    matchLabels:
      app.kubernetes.io/name: argocd-image-updater
  template:
    metadata:
      labels:
        app.kubernetes.io/name: argocd-image-updater
    spec:
      containers:
      - command:
        - /usr/local/bin/argocd-image-updater
        - run
        env:
        - name: ARGOCD_GRPC_WEB
          value: "true"
        - name: ARGOCD_SERVER
          value: "https://argo.mydomain.com"

time="2020-10-08T21:41:37Z" level=error msg="error while communicating with ArgoCD" argocd_server="https://argo.mydomain.com" grpc_web=true grpc_webroot= insecure=false plaintext=false
time="2020-10-08T21:41:37Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://https//argo.mydomain.com
ineering/application.ApplicationService/List\": dial tcp: lookup https on 100.64.0.10:53: no such host"

To Reproduce
Provide an https URL in the ARGOCD_SERVER env var either via configmap or in the deployment directly

Expected behavior

Would expect the fqdn lookup to return the ingress IP and not the cluster local IP. When attempting to use the cluster local service (e.g. leaving ARGOCD_SERVER empty) it then tries to use https to the local pod:

time="2020-10-08T21:47:56Z" level=error msg="error while communicating with ArgoCD" argocd_server=argocd-server.argocd grpc_web=true grp
c_webroot= insecure=true plaintext=false
time="2020-10-08T21:47:56Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://argocd-server.argocd:443/application
.ApplicationService/List\": read tcp 192.168.3.70:53584->192.168.0.17:8080: read: connection reset by peer"

This is with argocd-server running with the --insecure flag because if you try and run it without this flag, the error is then that the certificate it's using isn't valid.

Also, specifying INSECURE false vs. true in the argocd image updater seems to have no bearing on it's use of https:

time="2020-10-08T21:50:22Z" level=error msg="error while communicating with ArgoCD" argocd_server=argocd-server.argocd grpc_web=true grp
c_webroot= insecure=false plaintext=false
time="2020-10-08T21:50:22Z" level=error msg="Error: rpc error: code = Unknown desc = Post \"https://argocd-server.argocd:443/application
.ApplicationService/List\": read tcp 192.168.3.154:51664->192.168.1.64:8080: read: connection reset by peer"

Version
Argocd v1.7.6
Argocd image updater v.0.7.0

Is your feature request related to a problem? Please describe.
I'm really excited to see argocd-image-updater repository as this feature is something I really felt I was missing our compared with flux and others like keel.sh. I've recently started using & migrating our application delivery process over to argocd and have really enjoyed seeing the development teams actually love the tool.

We have tagged images with the githash for a long time, and im sure many others have and will continue to do so. It's using the version tagging built into our version control tool of choice.. git. This is basically the only blocker to me trying out this tool.

Our current workflow is for devs to PR their new image githash, after mering their code the the respective branch. I want to make this process better.

Describe the solution you'd like
I would like to be able monitor for new version of my image tagged with a githash and auto deploy them, in the same way that this tool enables SemVer images to be deployed.

Describe alternatives you've considered

• keel.sh -> again this is on SemVer so can't got that way
• flux -> I don't want to use two deployment tools, its just twice the maintenance for me
• Converting 40+ applications to use a release process means changing our CI pipelines for all those applications, and fundamentally the company culture to embrace a new process. This is harder and longer process than implementing a tool to do it.

Additional context

I've dealt with this a little bit and will give some context to what I'm currently doing.

We use App of Apps for better or worse to manage all the applications in our environment. (Environment maps to a cluster which maps to a project in argocd) We are also using Declarative config from a single repository to define our ArgoCD application in yaml. Hence I have a tool (ansible) to generate the application config files, and also to regenerate them as needed.

One of the handy feature for me, it for ansible to go look at the applications git repository on a specified branch and return me the latest githash on that branch. That then feeds into my ArgoCD application yaml file that's generated. PR that to the ops repo and then the app of apps will sync it out.

I'd like in some way to replicate that back into the image-updater.

So perhaps to help with version constraints of githash'd images, we could look at using a git tag as a reference point.
For example maybe:

argocd-image-updater.argoproj.io/image-list: <image>:git+<git-ref>
# could be:
argocd-image-updater.argoproj.io/image-list: <image>:git+staging
# compared with the SemVer:
argocd-image-updater.argoproj.io/image-list: nginx:~1.26

The idea being:

1. New image is available in container registry.
2. Argocd picks up the new change (webhook / poll) and stores new_hash
3. Argocd checks the constraint, notices it's git, and picks up the staging reference
4. Argocd checks the application repository for the referenced branch. (This may not be defined, but perhaps an annotation with the git url could be added to make this check easier, the credentials would have to be available to argo to query said repo of course).
5. Pulls the commit sha history for branch... and checks for new_hash in the commit history.
6. If in there, deploys. If not... it doesn't.

A further check could compare the date of new_hash with the existing hash in the application. Update but warn if the image is older that the current hash.
This might be a nice pattern for allow updates based on git branches. Something we use but there are many other strategies.

A side benefit of having argocd talk the git, is that it could potentially know when a new commit is available and show that a deployment is incoming. I.e. the time between merge of code in the app's repo and the CI building & pushing the image to the container registry.

Sorry that's a lot of ideas that bring man challenges, so ...

Basic request

Stage 1 - Just deploy the latest githash tagged image when available, with respect to sync options (manual / auto).

Stage 2 - Think about how we can improve the experience with more safeguards, like restricting to a git branch.

Are you planning on adding support for Azure Container Registry?

Describe the bug
kubectl apply -k base/ install is failing on v0.3.1 because directories are listed in the resources section. Should either move these directories to bases or list each file individually.

To Reproduce
create base/kustomization.yaml with the following contents:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

bases:
- github.com/argoproj-labs/argocd-image-updater/manifests/base/?ref=v0.3.1

run kubectl apply -k base/

Expected behavior
Manifests would be applied to the cluster

Additional context
The kustomization.yaml file is abbreviated and other resources relevant to our deployment have been omitted, but attempting install with both yields the same result.

Version
kubectl v1.18.6
kubernetes v1.17.9-eks-4c6976

Logs

$ kubectl apply -k base
error: AccumulateTarget: rawResources failed to read Resources: Load from path ./config failed: './config' must be a file (got d='/private/var/folders/pv/r1tbm8n92mx9t46kqx68bz6c0000gn/T/kustomize-669160585/manifests/base/config')

Is your feature request related to a problem? Please describe.
Some registries - such as quay.io - impose a rate limit on API requests. If a repository contains a large number of tags, the image updater may easily trigger these limits just by performing paginated requests to list the available tags. This can ultimately lead to the client IP address being blacklisted from further API access.

Describe the solution you'd like
We need a per-registry configuration for obeying rate limits imposed by the specific registry, so that we won't trigger any of these limits. This limit must be applied while listing paginated tags as well as fetching tag meta-data.

Per the latest docs argocd-image-updater won't reuse Argo CD repo credentials for Git write-back. Is there a technical reason for the limitation, a security concern, or other? It would be great if users who understand the security implications could configure reuse and avoid adding another annotation to each Application definition.

Is your feature request related to a problem? Please describe.

People are struggling with some of the more advanced configuration. This creates frustration and hinders adoptions.

Describe the solution you'd like

We should provide more and better explained examples in the docs, such as:

• adding a private registry
• how to use external authentication, including working examples on how to add third-party binaries to Image Updater
• selecting only specific tags
• complete walk-through to configure applications with multiple images (Helm and Kustomize)

Above list will grow. Please keep adding topics to this issue in the comments.

Is your feature request related to a problem? Please describe.

Argo CD Image Updater will consider all applications with appropriate annotations for update during processing. This might sometimes not be what the user want, especially during testing.

Describe the solution you'd like

We need a way to specify a pattern on the application name (or associated project) that has to match in order for Argo CD Image Updater to process a given application. This would be most appropriate on the command line, i.e. --applications app1,app2,..., possibly also in the project/application notation, with wild card support.

Has anyone experience this with the image updater ? This was initially working fine, I've recreated it a couple of time but the same issue persists.

time="2021-02-22T23:52:33Z" level=info msg="argocd-image-updater v99.9.9+457b52f starting [loglevel:DEBUG, interval:2m0s, healthport:8080]"
time="2021-02-22T23:52:33Z" level=debug msg="rate limit for https://90152327234848.dkr.ecr.us-east-1.amazonaws.com is 2147483647"
time="2021-02-22T23:52:33Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2021-02-22T23:52:33Z" level=debug msg="Creating in-cluster Kubernetes client"
time="2021-02-22T23:52:33Z" level=debug msg="Using ArgoCD API credentials from environment ARGOCD_TOKEN"
time="2021-02-22T23:52:33Z" level=info msg="ArgoCD configuration: [apiKind=kubernetes, server=argocd-server.argocd.svc.cluster.local, auth_token=true, insecure=true, grpc_web=true, plaintext=true]"
time="2021-02-22T23:52:33Z" level=info msg="Starting health probe server TCP port=8080"
time="2021-02-22T23:52:33Z" level=info msg="Starting metrics server on TCP port=8081"
time="2021-02-22T23:52:33Z" level=info msg="Warming up image cache"
time="2021-02-22T23:52:33Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 6 registries"
time="2021-02-22T23:52:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:52:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:54:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:54:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:56:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-02-22T23:56:33Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-02-22T23:58:33Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"

Is your feature request related to a problem? Please describe.
Currently, to change the log level of argocd-image-updater, it is necessary to modify the deployment spec. This is unnecessarily complicated and should be simplified.

Describe the solution you'd like
It should be possible to set the log level from an environment variable, and use an environment reference to the argocd-image-updater-config config map to actually set the level, so users can easily change the log level without being forced to edit any deployment specs.

error while communicating with ArgoCD" argocd_server="server IP" grpc_web=true grpc_webroot= insecure=false

"Error: rpc error: code = Unknown desc = Post "https://ServerIp/application.ApplicationService/List\": x509: cannot validate certificate for ServerIp because it doesn't contain any IP SANs"

Though I have mentioned insecure=false, why certs are getting checked?

Any help would be highly appreciated.

Is your feature request related to a problem? Please describe.

Currently, ArgoCD Image Updater only polls container registries for new tags at a given interval. Depending on the number of images and registries to be checked, this can lead to an overwhelming number of requests and takes a lot of time.

Describe the solution you'd like

Update checks for images should also be triggered asynchronously, i.e. by a webhook on image push to the registry.

Is your feature request related to a problem? Please describe.
Currently, the only way to filter tags is to provide a tag-match annotation, which lets you define a pattern that has to match a tag's name in order for it to be considered. In some cases, it would be much better to invert the matcher logic and to ignore a list of tags.

Describe the solution you'd like
A new annotation containing a list of tags that should be ignored, even if matched by tag-match patterns. This could be for example argocd-image-updater.argoproj.io/<image_name>.tag-ignore: tag1, tag2, tag3 - maybe even using glob patterns (but not regexps).

Describe the bug

ArgoCD image updater cannot find the login for a registry if https:// prefix is missing in secret. If prefix is added to secret it works fine.

To Reproduce

I login to a registry using

docker login ghcr.io

and use the resulting ~/.docker/config.json file to create a secret of type kubernetes.io/dockerconfigjson.

Then I start ArgoCD image updater and get the log:

time="2020-09-25T19:56:16Z" level=error msg="Could not set registry endpoint credentials: no valid auth entry for registry https://ghcr.io found in image pull secret ...  registry=ghcr.io"

If the secret is created with docker login https://ghcr.io it works fine.

Expected behavior

ArgoCD image updater should find the login even if https:// prefix is missing in secret.

Additional context

Version
v0.6.2

Describe the bug
I followed the instructions, but argo image updater does not work.

To Reproduce
Steps to reproduce the behavior:
I have annotated the application as desired as below:
argocd-image-updater.argoproj.io/myimage.helm.image-name: nitinkansal/argo-workflow
argocd-image-updater.argoproj.io/myimage.update-strategy: latest

Expected behavior
A clear and concise description of what you expected to happen.
It should search for the latest and deploy the same.

Additional context
Add any other context about the problem here.

Version
Please tell us about the version you encountered the issue with

argocd-image-updater: v99.9.9+457b52f

Logs
Please paste any relevant logs here
time="2021-03-09T15:15:50Z" level=info msg="argocd-image-updater v99.9.9+457b52f starting [loglevel:DEBUG, interval:2m0s, healthport:8080]"
time="2021-03-09T15:15:50Z" level=debug msg="rate limit for https://registry-1.docker.io is 2147483647"
time="2021-03-09T15:15:50Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2021-03-09T15:15:50Z" level=debug msg="Creating in-cluster Kubernetes client"
time="2021-03-09T15:15:50Z" level=debug msg="Using ArgoCD API credentials from environment ARGOCD_TOKEN"
time="2021-03-09T15:15:50Z" level=info msg="ArgoCD configuration: [apiKind=kubernetes, server=<LoadBalancer_IP>, auth_token=true, insecure=true, grpc_web=false, plaintext=true]"
time="2021-03-09T15:15:50Z" level=info msg="Starting health probe server TCP port=8080"
time="2021-03-09T15:15:50Z" level=info msg="Starting metrics server on TCP port=8081"
time="2021-03-09T15:15:50Z" level=info msg="Warming up image cache"
time="2021-03-09T15:15:50Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2021-03-09T15:15:50Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-03-09T15:15:50Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"
time="2021-03-09T15:17:50Z" level=info msg="Starting image update cycle, considering 0 annotated application(s) for update"
time="2021-03-09T15:17:50Z" level=info msg="Processing results: applications=0 images_considered=0 images_skipped=0 images_updated=0 errors=0"

We would like to deploy the ArgoCD Image Updater - but in our environments, absolutely everything is declaratively deployed through kubernetes resources (Generally with Helm charts). I cannot see any way to declaratively create an authentication token for the image-updater in our ArgoCD system.

I really think that along the lines of #138, I consider the argocd-image-updater simply an additional component to the ArgoCD system.. so it should be able to be deployed along side ArgoCD and just leverage the various secrets and credentials that the ArgoCD system sets up already.

Describe the solution you'd like
Bypass token authentication and be able to install argocd-image-updater along side arogcd without any special work for authentication or authorization.

Is your feature request related to a problem? Please describe.

We currently publish binaries via GitHub release page for linux/amd64 architectures.

Describe the solution you'd like

Additional binaries for other architectures - linux/arm64 and darwin/amd64 - should be build & published via the releases page, so that people on that architectures can benefit from features of argocd-image-updater test command.

Is your feature request related to a problem? Please describe.

Currently, the image updater retrieves a list of applications using Argo CD API. That requires the creation of an Argo CD token and connection options (such as grpc-web, insecure etc).

We might simplify the initial configuration if the updater is running in the same namespace as Argo CD. In this case list of applications can be extracted using Kubernetes client.

Describe the solution you'd like

Add --applications-source flag that takes two parameters: argocd, namespace. If namespace is specified then the updater should read applications from the current namespace.

Additional context
I think this might improve adoption significantly since this way we support no configuration installation. The user just needs to run kubectl apply -n argocd -f ... (or add one more remote base to kustomization file) and the updater should work with public image registries out of the box.

It is still good to support connecting using argocd API. Docker registry might be not available from Argo CD namespace or updater cannot be installed into the same namespace for security reasons.

time="2021-02-25T22:01:22Z" level=debug msg="Using version constraint 'latest' when looking for a new tag" alias=msa_msa-ui application=xxxxxxxxxxxxxxxx image_tag="" registry=XXXXXXXXXX.dkr.ecr.us-east-1.amazonaws.com
time="2021-02-25T22:01:23Z" level=debug msg="found 1 from 1 tags eligible for consideration" image=XXXXXXX.dkr.ecr.us-east-1.amazonaws.com/xxx/xxx
panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x18d7769]

goroutine 55 [running]:
github.com/argoproj-labs/argocd-image-updater/pkg/argocd.UpdateApplication(0x1db6178, 0x1fb4f60, 0xc00046a5c0, 0xc0004146d0, 0xc000427000, 0x1fcd101, 0x0, 0x0, 0x0, 0x0, ...)
/src/argocd-image-updater/pkg/argocd/update.go:137 +0xb09
main.runImageUpdater.func1(0xc00011c870, 0xc000418c40, 0xc0003f0590, 0xc00034d9e0, 0xc000515101, 0xc0003f0594, 0xc000500270, 0xb, 0x0, 0x0, ...)
/src/argocd-image-updater/cmd/main.go:132 +0x18f
created by main.runImageUpdater
/src/argocd-image-updater/cmd/main.go:129 +0x8f6

Argo CD Image Updater should export some metrics about how it behaves.

Items to be included in the first throw:

• Number of applications watched
• Number of images considered to be updated
• Number of images actually updated
• Number of image update errors
• Number of API requests to the registry

Is your feature request related to a problem? Please describe.
First of all, this is an excellent addition to Argo and I think it should definitely be pulled in to the main project. This is an extremely critical feature to a GitOps flow imo.

Basically, the install process right now is cumbersome and hard to fully automate.

Current process:

• Install raw manifests
• Manually update image-updater configmap with repositories and Argo URLs
• Create a local account in my argo-cd HelmRelease for image-updater (not a big deal)
• Generate a new token for that user
• Create a kubernetes secret from that token
• Restart image-updater pod

Describe the solution you'd like

A helm chart would be a great start. I think a lot of this, if not all, could be automated with helm hooks or templating. Not completely sure about the user token though. Happy to contribute one if it makes sense.

Describe alternatives you've considered
An alternative would be to fully integrate this component into Argo so no end-user configuration is required.

Additional context
N/A

Describe the bug
Per the docs, the correct way to use argocd-image-updater with Kustomize is to use the image name (e.g. argoproj/argocd) as an alias. However, Kubernetes only allows one slash in an annotation key, so I'm unable to use the alias for other argocd-image-updater options.

To Reproduce

1. Create a Kustomize overlay with a slash in the image name:

apiVersion: kustomize.config.k8s.io/v1beta1
kind: Kustomization

images:
  - name: hjacobs/kube-resource-report
namespace: kube-resource-report
resources:
  - github.com/hjacobs/kube-resource-report/deploy?ref=20.7.3

2. Create an Application manifest pointing to the overlay, with argocd-image-updater annotations:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/image-list: hjacobs/kube-resource-report=<container_repo_url>/kube-resource-report
    argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy: latest
  finalizers:
    - resources-finalizer.argocd.argoproj.io
  name: kube-resource-report
  namespace: argocd
spec:
  destination:
    namespace: kube-resource-report
    server: https://kubernetes.default.svc
  project: cluster-services
  source:
    path: kube-resource-report/
    repoURL: <config_repo_url>
    targetRevision: main
  syncPolicy:
    automated:
      prune: true
    syncOptions:
      - CreateNamespace=true

Expected behavior
Creation of an Argo CD Application that continuously deploys the latest version of the <container_repo_url>/kube-resource-report container image.

Version
0.7.0

Logs

error="Application.argoproj.io \"cluster-services-krr-bdatasf-npd-us-east4-ng\" is invalid: metadata.annotations: Invalid value: \"argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy\": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')"
2020-10-01T20:36:15.016Z	ERROR	controller-runtime.controller	Reconciler error	{"controller": "applicationset", "name": "cluster-services-kube-resource-report", "namespace": "argocd", "error": "Application.argoproj.io \"cluster-services-krr-bdatasf-npd-us-east4-ng\" is invalid: metadata.annotations: Invalid value: \"argocd-image-updater.argoproj.io/hjacobs/kube-resource-report.update-strategy\": a qualified name must consist of alphanumeric characters, '-', '_' or '.', and must start and end with an alphanumeric character (e.g. 'MyName',  or 'my.name',  or '123-abc', regex used for validation is '([A-Za-z0-9][-A-Za-z0-9_.]*)?[A-Za-z0-9]') with an optional DNS subdomain prefix and '/' (e.g. 'example.com/MyName')"}

Is your feature request related to a problem? Please describe.

Currently, Docker images for argocd-image-updater are only built & published for amd64 architecture. People might want to run on arm64 architectures.

Describe the solution you'd like

We should build & provide official Docker images for arm64 architecture.

Describe the bug
I want to use the new Github Container Registry ghcr.io but I get a strange error message "Could not get tags from registry: unexpected manifest schema was received from registry"

To Reproduce
My config map contains:

  registries.conf: |
    registries:
    - name: Github Container Registry
      api_url: https://ghcr.io
      ping: no
      prefix: ghcr.io
      credentials: pullsecret:argocd-image-updater/regcred

Expected behavior
ghcr.io should be supported.

Additional context

Version
v0.6.1

Logs

time="2020-09-24T21:00:36Z" level=info msg="argocd-image-updater v0.6.1 starting [loglevel:INFO, interval:2m0s, healthport:8080]"
time="2020-09-24T21:00:36Z" level=info msg="Loaded 1 registry configurations from /app/config/registries.conf"
time="2020-09-24T21:00:36Z" level=info msg="ArgoCD configuration: [server=argocd-server.argocd, auth_token=true, insecure=false, grpc_web=false, plaintext=true]"
time="2020-09-24T21:00:36Z" level=info msg="Starting health probe server TCP port=8080"
time="2020-09-24T21:00:36Z" level=info msg="Warming up image cache"
time="2020-09-24T21:00:37Z" level=error msg="Could not get tags from registry: unexpected manifest schema was received from registry: application/vnd.docker.distribution.manifest.v2+json (registry may not support the manifest type(s) you want: [application/vnd.docker.distribution.manifest.v1+prettyjws application/vnd.docker.distribution.manifest.v1+json])" alias=techwiki application=techwiki image_name=windsource/techwiki image_tag=latest registry=ghcr.io
time="2020-09-24T21:00:37Z" level=info msg="Finished cache warm-up, pre-loaded 0 meta data entries from 5 registries"
time="2020-09-24T21:00:37Z" level=info msg="Starting image update cycle, considering 1 annotated application(s) for update"
time="2020-09-24T21:00:38Z" level=error msg="Could not get tags from registry: unexpected manifest schema was received from registry: application/vnd.docker.distribution.manifest.v2+json (registry may not support the manifest type(s) you want: [application/vnd.docker.distribution.manifest.v1+prettyjws application/vnd.docker.distribution.manifest.v1+json])" alias=techwiki application=techwiki image_name=windsource/techwiki image_tag=latest registry=ghcr.io
time="2020-09-24T21:00:38Z" level=info msg="Processing results: applications=1 images_considered=1 images_skipped=0 images_updated=0 errors=1"

Describe the bug
Currently built argoprojlabs/argocd-image-updater images lack SSH client resulting in errors when trying to use git write back feature with SSH git repositories.

To Reproduce

• Create ArgoCD application using SSH repository with annotations required by argocd-image-updater:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  name: some-app
  namespace: argocd
  finalizers:
  - resources-finalizer.argocd.argoproj.io
  annotations:
    argocd-image-updater.argoproj.io/image-list: image=[...]
    argocd-image-updater.argoproj.io/write-back-method: git
    argocd-image-updater.argoproj.io/image.update-strategy: latest
    argocd-image-updater.argoproj.io/image.ignore-tags: latest
 spec:
  destination:
    namespace: some-ns
    server: https://kubernetes.default.svc
  project: default
  source:
    path: some-path
    repoURL: [email protected]:repopath.git
    targetRevision: HEAD

• Wait for argocd-image-updater to attempt git writeback
• argocd-image-updater executes git which errors out due to missing ssh binary

Expected behavior

• Git write back succeeds

Additional context

FROM argoprojlabs/argocd-image-updater@sha256:a7f435f888d2f98f0bd477a36f3d4903d92755ee347365d33e414ee37c34ff26

USER 0

RUN apk update && apk add openssh-client && adduser --home "/app" --disabled-password --uid 1000 argocd

USER 1000

Above changes in addition to mounting ssh_known_hosts file to /app/config/ssh directory (probably needs to be documented) fix the issue.

Version
master - commit 457b52f

Is your feature request related to a problem? Please describe.
We need to notify another systems when a version has changed and which is the new tag being used.

Describe the solution you'd like
I'd like to be able to monitor a kubernetes event containing at least:

• resource type ("deployment")
• resource name ("foo")
• tag used ("1.2.3")
• namespace ("foo")
• optionally, previous tag
• optionally, image name and/or repository.

This way we could add another piece to the pipeline to notify external services.

Describe alternatives you've considered
I've considered:

• to use ArgoCD-notifications, but it only monitors Applications, so it won't know the tag being used.
• to use kubernetes-event-exporter, configuring a label with the tag, but after running argocd-image-updater the tag disapears, and events might be duplicated due to replication.

Additional context
By creating an event, other systems can take it to perform other different actions: notifications (email, slack, pagerduty, ...), maintain a dashboard, monitoring (grafana with tags showing the tag currently used), traceability (logs), ...

Describe the bug

The image updater does not seem to pull the latest image properly when using a Nexus image repository. I have enabled trace logs and have not been able to find any threads that would cause this. Looking at the code, it should dump out a list sorted by date and that list in the logs is definitely wrong. I am wondering if this is because creation metadata is buried in Nexus API.

To Reproduce
Steps to reproduce the behavior:

1. Use Nexus image repository to host images
2. Add image updater annotations with latest update strategy. I do get different results using latest-last and latest-first sorting modes on the repository itself, which seems odd.
3. Observe latest image not being set

Expected behavior
Latest image should be used

Version
v0.8.0+961de70

Hi,

I use Google Container Registry for hosting my docker images. When I tag my docker image with SHA1 tag and latest tag, argocd-image-updater found two tag for latest strategy image.

So it first updates the pod image with the tag SHA1 .... then it updates with the latest tag...

This operation is executed in a loop

To Reproduce
Steps to reproduce the behavior:

# Build with two tag
docker build -t eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596 -t eu.gcr.io/<gcp-project-id>/<image-name>:latest .

# Push image with two tag
docker push eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596
docker push eu.gcr.io/<gcp-project-id>/<image-name>:latest

Application YAM

apiVersion: argoproj.io/v1alpha1
...
    annotations:
    argocd-image-updater.argoproj.io/image-list: my_alias=eu.gcr.io/<gcp-project-id>/<image-name>
    argocd-image-updater.argoproj.io/my_alias.update-strategy: latest
....

Expected behavior
I think argocd-image-updater should be based on image digest for determine the really latest image.

Version
argocd-image-updater:0.8

Workaround

I use ignore_tags for explicitly ignoring latest tag

apiVersion: argoproj.io/v1alpha1
...
    annotations:
    argocd-image-updater.argoproj.io/image-list: my_alias=eu.gcr.io/<gcp-project-id>/<image-name>
    argocd-image-updater.argoproj.io/my_alias.update-strategy: latest
    argocd-image-updater.argoproj.io/my_alias.ignore-tags: latest
....

Logs

time="2021-01-27T16:51:24Z" level=debug msg="Cache hit for eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596"
time="2021-01-27T16:51:24Z" level=debug msg="Cache hit for eu.gcr.io/<gcp-project-id>/<image-name>:latest"
time="2021-01-27T16:51:24Z" level=debug msg="found 2 from 2 tags eligible for consideration" image="eu.gcr.io/<gcp-project-id>/<image-name>:07bfd2596"

Describe the bug
If you have a parameter in the Application, and there's a new image that's triggering an update of the Argo Application, it'll create an infinite sync loop.

To Reproduce
Add this to a Helm deployment's Application manifest:

spec:
  source:
    helm:
      parameters:
      - name: customVariable
        value: customValue

Expected behavior
Should not be an infinite loop of sync.

Additional context
N/A

Version
v0.8.0 - sha256:e31a6c1dce2cfbe12b84f1a68b6e6c85f4ca227c32a6c5bab20e2dc053457e2e

Logs
N/A

Is your feature request related to a problem? Please describe.

We need to find a proper way how we can synchronize our changes back to Git. Currently, we leverage Argo CD API to set the application parameters for image override, and Argo CD will update the Application resource with parameter overrides in the Kubernetes cluster. These changes need to be persisted somehow.

Describe the solution you'd like

I think the details about this need to be discussed and designed properly. This issue is open to collect all kind of ideas & discussions.

Is your feature request related to a problem? Please describe.
Currently, to get the list of tags to consider for update, all tags returned by the registry for any given image are checked against the version constraint. This might result in the wrong image chosen for update.

Describe the solution you'd like
User should be able to pre-filter the list returned by the registry so that version constraints are checked only against a given set of tags. This could be implemented by an option such as argocd-image-updater.argoproj.io/<image_alias>.match-tags: <function>:<argument>.

An example to match only tags whose name end with -foo could look like follows (with a regexp function):

argocd-image-updater.argoproj.io/<image_alias>.match-tags: regexp:.*-foo$