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 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 We wish to have a generic kustomization.yaml without an image tag. We wish to use the argocd image updater to set the image tags. We use a generic image name called image. We first tried without the image alias in kustomization.yaml. In that case the image updater fails to update or find the image alias. Apparently Kustomize needs to do a first pass to change the image alias to the final image. So then we add the image newName. But without a newTag the application crashes.

To Reproduce A kustomization.yaml with the contents:

images:
- name: image
  newName: some-registry.com/some-image

with Argo Application with annotations:

argocd-image-updater.argoproj.io/image-list: image=some-registry.com/some-image
argocd-image-updater.argoproj.io/image.kustomize.image-name: some-registry.com/some-image
argocd-image-updater.argoproj.io/image.update-strategy: latest

This creates a panic and the application crashes

Expected behavior Image updater should allow newTag to be empty because it is valid according to Kustomize. Kustomize applies latest as the image tag.

Additional context We use a generic image name in our deployment.yaml files and rely on kustomize image aliases to set the correct image. We are also not clear with the argocd-image-updater.argoproj.io/image.kustomize.image-name is supposed to designate.

Version v99.9.9+ccd78aa

Logs

 panic: runtime error: invalid memory address or nil pointer dereference
[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0x196e453]
goroutine 22 [running]:
github.com/argoproj-labs/argocd-image-updater/pkg/tag.(*ImageTag).IsDigest(...)
        /src/argocd-image-updater/pkg/tag/tag.go:96
github.com/argoproj-labs/argocd-image-updater/pkg/tag.(*ImageTag).Equals(...)
        /src/argocd-image-updater/pkg/tag/tag.go:102
github.com/argoproj-labs/argocd-image-updater/pkg/argocd.UpdateApplication(0xc000c73b78, 0xc000c45310, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0)
        /src/argocd-image-updater/pkg/argocd/update.go:252 +0xc43
main.runImageUpdater.func1(0xc000193e50, 0xc0001a57a0, 0xc000c35ff0, 0xc000c45310, 0xc000050ae0, 0x1, 0xc000c35ff4, 0xc00071fd40, 0x14, 0xc0007253b0, ...)
        /src/argocd-image-updater/cmd/main.go:160 +0x23c
created by main.runImageUpdater
        /src/argocd-image-updater/cmd/main.go:147 +0xa3d

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"

Describe the bug argocd-image-updater: v0.10.3 argocd: v2.1.2 gitrepo: helm

Strategy

argocd-image-updater.argoproj.io/write-back-method: argocd
argocd-image-updater.argoproj.io/image-list: myimagealias=gcr.io/project-name/images-path/my-image-name:my-tag-name
argocd-image-updater.argoproj.io/myimagealias.update-strategy: digest

I'm using the digest strategy for image updating and from argocd-image-updater end all seems to work fine, and I'm getting the successfully updated message. Yet ArgoCD doesn't seem to update the image.

time="2021-09-16T19:47:35Z" level=info msg="Successfully updated the live application spec" application=dev-environment

When I check the Argo CD, I can see the following has been added to parameters, but it does't trigger an update.

image.name
  gcr.io/project-name/images-path/my-image-name
image.tag
 sha256:xxxxxxx

My approach / requirement is to have argocd as the write-back method and only the team members updating the deployment repo with image details and repo tags per each environment.

1. Can anyone tell me what I might be doing wrong here?
2. Any help on fixing this issue is appreciated

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"

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

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've started using the digest update strategy for a few of my images and found that it quickly runs me into docker hub pull rate limits, I'd like argo image updater to only check for new images every few hours instead of every few minutes to avoid running into this rate limit.

Describe the solution you'd like I'd like to see a setting of some sort to configure the interval at which argocd image updater checks for image updates. Perhaps this setting could also be per-registry since not all registries have the same rate limits.

Describe alternatives you've considered I know that I can set up a "pull-through" registry mirror but if I understand correctly, it would still generate the same amount of api calls when constantly fetching digests for tags right?

Is your feature request related to a problem? Please describe. I would like to use argocd-image-updater to update some container images I have pinned to the latest tag (specifically linuxserver.io container images) because some image have "specific" tags are very long and nonsensical e.g. linuxserver/qbittorrent:version-14.3.4.99202103270406-7346-81a7b0c03ubuntu20.04.1. I realize this locking an image tag to latest isn't usually a good idea but it's necessary in this case. I can't use the "latest" update strategy because the latest images are pre-release builds I don't want to use.

I initially thought I could do something like:

annotations:
    argocd-image-updater.argoproj.io/image-list: "qbittorrent=linuxserver/qbittorrent"
    argocd-image-updater.argoproj.io/qbittorrent.update-strategy: name
    argocd-image-updater.argoproj.io/qbittorrent.allow-tags: "regexp:^latest$"

But then I quickly realized that that will only check that the deployment is locked to linuxserver/qbittorrent:latest but doesn't check the digest to see if that tag has been updated upstream at the registry since they are mutable.

Describe the solution you'd like I'd like to see a new strategy added that just watches a single tag for digest updates and then restarts the relevant deployment (given that it is using ImagePullPolicy: Always) so that it pulls an updated image.

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), ...

Is your feature request related to a problem? Please describe. ArgoCD v2.6.0-rc1 introduced a new field called sources, which overrides the source field of the application resource. When setting image-updater on such application, we get: level=warning msg="skipping app 'myapp-staging' of type '' because it's not of supported source type" application=myapp-staging which indicates that image-updater does not recognize this application as of valid source type. Describe the solution you'd like Seems like a minor update could make image-updater aware of this new sources field and apply some logic accordingly

Describe alternatives you've considered Couldn't find any

Additional context None

I'm facing something new and looking for help.

time="2022-12-27T14:59:21Z" level=info msg="Successfully updated image 'ghcr.io/<repo-name>/<image>:1.0.1' to 'ghcr.io/<repo-name>/<image1>:1.0.5', but pending spec update (dry run=false)" alias=image application=example-app image_name=<repo-name>/<image> image_tag=1.0.1 registry=ghcr.io
time="2022-12-27T14:59:21Z" level=info msg="Committing 1 parameter update(s) for application example-app" application=example-app
time="2022-12-27T15:01:22Z" level=error msg="Could not update application spec: stat /tmp: no such file or directory" application=example-app

Originally posted by @emon5122 in https://github.com/argoproj-labs/argocd-image-updater/issues/510#issuecomment-1365966222

Describe the bug

argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:47Z" level=error msg="error fetching metadata for twingate/connector:1.43.0: could not fetch manifest sha256:4fa7723a70c955819f75d398718b6bf84b457638fa8fa3a0be47c44ab275df3c: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=
argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:47Z" level=error msg="error fetching metadata for twingate/connector:1.44.0: could not fetch manifest sha256:0ebc62338d9579f5dd134c2ee46bce77ad43c73766f98cf088de371ec426151f: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=
argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:47Z" level=error msg="error fetching metadata for twingate/connector:1.45.0: could not fetch manifest sha256:6e4a5e0cd444534bd4f808b90a65c0d47d49275fb13785e32d16ea5b8e674521: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=
argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:48Z" level=error msg="error fetching metadata for twingate/connector:1.46.0: could not fetch manifest sha256:6e8480f87c2c1ea48a946427b8da881fac95387a8aed31f7bf00c6e02feb31bb: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=
argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:48Z" level=error msg="error fetching metadata for twingate/connector:1.47.0: could not fetch manifest sha256:77cb2cd45bb9a001ee780f51011054722e4f5d9a1a30b478c95a17d70b8de8af: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=
argocd-image-updater-5b589d4576-8lqvx argocd-image-updater time="2022-12-27T13:31:51Z" level=error msg="Error fetching metadata for twingate/connector:1.47.0 - neither V1 or V2 or OCI manifest returned by registry: toomanyrequests: You have reached your pull rate limit. You may increase the limit by authenticating and upgrading: https://www.docker.com/increase-rate-limit" alias=twingate application=twingate-k8s-connector image_name=twingate/connector image_tag=1.47.0 registry=

A push to repo with 1.42 tag as the newest available was performed.

Here's app configuration:

apiVersion: argoproj.io/v1alpha1
kind: Application
metadata:
  annotations:
    argocd-image-updater.argoproj.io/git-branch: development:image-updater{{range .Images}}-{{.Name}}-{{.NewTag}}{{end}}
    argocd-image-updater.argoproj.io/image-list: twingate=twingate/connector
    argocd-image-updater.argoproj.io/twingate.allow-tags: regexp:^1\.[0-9]+\.[0-9]+$
    argocd-image-updater.argoproj.io/twingate.kustomize.image-name: twingate/connector
    argocd-image-updater.argoproj.io/twingate.update-strategy: latest
    argocd-image-updater.argoproj.io/write-back-method: git:secret:argocd/bitbucket-creds
    argocd-image-updater.argoproj.io/write-back-target: kustomization:/bases/twingate-k8s-connector
  name: twingate-k8s-connector
  namespace: argocd

Expected behavior

Application should not be processed when pull rate limit is reached because otherwise it will produce misleading pushes.

Version v0.12.1

Describe the bug

Assuming two tags are being pointed to the same image SHA (see attached screenshot)

/usr/local/bin $ ./argocd-image-updater test quay.io/fairwinds/polaris --semver-constraint 7.2.x | grep "latest image"
time="2022-12-23T08:48:22Z" level=info msg="latest image according to constraint is quay.io/fairwinds/polaris:7.2" application=test image_alias= image_name=quay.io/fairwinds/polaris registry_url=quay.io
/usr/local/bin $ ./argocd-image-updater test quay.io/fairwinds/polaris --semver-constraint 7.2.x | grep "latest image"
time="2022-12-23T08:48:27Z" level=info msg="latest image according to constraint is quay.io/fairwinds/polaris:7.2.0" application=test image_alias= image_name=quay.io/fairwinds/polaris registry_url=quay.io
/usr/local/bin $

With constraint set to 7.2.x I would expect always having 7.2.0 as a return tag.

Version

/usr/local/bin $ ./argocd-image-updater version
argocd-image-updater: v0.12.1+16cff2e
  BuildDate: 2022-12-06T23:42:50Z
  GitCommit: 16cff2e66bcce86ba3ba034788ab5cbf18d8ed88
  GoVersion: go1.17.8
  GoCompiler: gc
  Platform: linux/amd64

Describe the bug

Invoking argocd-image-updater test prints out:

...
# Check for the latest built image for a tag that matches a pattern
argocd-image-updater test nginx --allow-tags '^1.19.\d+(\-.*)*$' --update-strategy latest
...

So lets test it:

/usr/local/bin $ argocd-image-updater test nginx --allow-tags '^1.19.\d+(\-.*)*$' --update-strategy latest
DEBU[0000] Creating in-cluster Kubernetes client
WARN[0000] Invalid match option syntax '^1.19.\d+(\-.*)*$', ignoring  image_alias= image_name=nginx registry_url=
INFO[0000] retrieving information about image            image_alias= image_name=nginx registry_url=
INFO[0000] Fetching available tags and metadata from registry  application=test image_alias= image_name=nginx registry_url=
DEBU[0000] Using canonical image name 'library/nginx' for image 'nginx'  application=test image_alias= image_name=nginx registry_url=
INFO[0000] Found 0 tags in registry                      application=test image_alias= image_name=nginx registry_url=
INFO[0000] no newer version of image found               application=test image_alias= image_name=nginx registry_url=

Reason theres no images found is most likely other warning about invalid match option syntax, altho regex compiles correctly.

Am I missing anything there?

Version

/usr/local/bin $ argocd-image-updater version
argocd-image-updater: v0.12.1+16cff2e
  BuildDate: 2022-12-06T23:42:50Z
  GitCommit: 16cff2e66bcce86ba3ba034788ab5cbf18d8ed88
  GoVersion: go1.17.8
  GoCompiler: gc
  Platform: linux/amd64