Automatic container image update for Argo CD

Argo CD Image Updater

Integration tests Documentation Status codecov Go Report Card

Introduction

Argo CD Image Updater is a tool to automatically update the container images of Kubernetes workloads which are managed by Argo CD. In a nutshell, it will track image versions specified by annotations on the Argo CD Application resources and update them by setting parameter overrides using the Argo CD API.

Currently it will only work with applications that are built using Kustomize or Helm tooling. Applications built from plain YAML or custom tools are not supported yet (and maybe never will).

Documentation

Read the documentation for more information on how to setup and run Argo CD Image Updater and to get known to it's features and limitations.

Above URL points to the documentation for the current release. If you are interested in documentation of upcoming features, check out the the latest documentation which is up-to-date with the master branch.

Current status

Argo CD Image Updater is under active development. We would not recommend it yet for critical production workloads, but feel free to give it a spin.

We're very interested in feedback on usability and the user experience as well as in bug discoveries and enhancement requests.

Important note: Until the first stable version (i.e. v1.0) is released, breaking changes between the releases must be expected. We will do our best to indicate all breaking changes (and how to un-break them) in the Changelog

Contributing

You are welcome to contribute to this project by means of raising issues for bugs, sending & discussing enhancement ideas or by contributing code via pull requests.

In any case, please be sure that you have read & understood the currently known design limitations before raising issues.

Also, if you want to contribute code, please make sure that your code

  • has its functionality covered by unit tests (coverage goal is 80%),
  • is correctly linted,
  • is well commented,
  • and last but not least is compatible with our license and CLA

Please note that in the current early phase of development, the code base is a fast moving target and lots of refactoring will happen constantly.

License

argocd-image-updater is open source software, released under the Apache 2.0 license

Things that are planned (roadmap)

The following things are on the roadmap until the v1.0 release

  • Extend Argo CD functionality to be able to update images for other types of applications.

  • Extend Argo CD functionality to write back to Git

  • Provide web hook support to trigger update check for a given image

  • Use concurrency for updating multiple applications at once

  • Improve error handling

  • Support for image tags with i.e. Git commit SHAs

For more details, check out the v1.0.0 milestone

Frequently asked questions

Does it write back the changes to Git?

We're happy to announce that as of v0.9.0 and Argo CD v1.9.0, Argo CD Image Updater is able to commit changes to Git. It will not modify your application's manifests, but instead writes Parameter Overrides to the repository.

We think that this is a good compromise between functionality (have everything in Git) and ease-of-use (minimize conflicts).

Are there plans to extend functionality beyond Kustomize or Helm?

Not yet, since we are dependent upon what functionality Argo CD provides for these types of applications.

Will it ever be fully integrated with Argo CD?

In the current form, probably not. If there is community demand for it, let's see how we can make this happen.

Comments
  • Support ECR authentication

    Support ECR authentication

    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.

  • Update does not seem to happen

    Update does not seem to happen

    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?

  • Kustomize aliases without newTag defined result in a nil pointer dereference and application crash

    Kustomize aliases without newTag defined result in a nil pointer dereference and application crash

    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
    
  • does not work as expected

    does not work as expected

    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"

  • Digest is not working (Digest, Tag, Helm)

    Digest is not working (Digest, Tag, Helm)

    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
  • Cannot use Github Container Registry

    Cannot use Github Container Registry

    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"
    
  • Not able to use Docker Hub Registry

    Not able to use Docker Hub Registry

    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!

  • ARGOCD_SERVER doesn't honor fqdn

    ARGOCD_SERVER doesn't honor fqdn

    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

  • Add configurable time interval/delay between fetching for updated images

    Add configurable time interval/delay between fetching for updated images

    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?

  • Add update strategy to restart deployment if digest for same tag has changed

    Add update strategy to restart deployment if digest for same tag has changed

    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.

  • Create events for changes

    Create events for changes

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

  • Support Multiple Sources as per ArgoCD v2.6.0 New Field

    Support Multiple Sources as per ArgoCD v2.6.0 New Field

    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

  • Could not update application spec: stat /tmp: no such file or directory

    Could not update application spec: stat /tmp: no such file or directory

    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

  • When pull rate limit is reached application should not be processed

    When pull rate limit is reached application should not be processed

    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

  • Inconsistent semver return results

    Inconsistent semver return results

    Describe the bug

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

    Zrzut ekranu 2022-12-23 o 09 50 48

    /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
    
  • Testing regexp for latest updates strategy

    Testing regexp for latest updates strategy

    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
    
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.

What is Argo Workflows? Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflow

Dec 10, 2021
Notifications for Argo CD
Notifications for Argo CD

Argo CD Notifications Argo CD Notifications continuously monitors Argo CD applications and provides a flexible way to notify users about important cha

Nov 27, 2022
Argo CD ApplicationSet Controller

The ApplicationSet controller manages multiple Argo CD Applications as a single ApplicationSet unit, supporting deployments to large numbers of clusters, deployments of large monorepos, and enabling secure Application self-service.

Dec 14, 2022
A Kubernetes operator for managing Argo CD clusters.

Argo CD Operator A Kubernetes operator for managing Argo CD clusters. Documentation See the documentation for installation and usage of the operator.

Dec 14, 2022
Support for extending Argo CD

Argo CD Extensions To enable Extensions for your Argo CD cluster will require just a single kubectl apply. Here we provide a way to extend Argo CD suc

Dec 20, 2022
Argo-CD Autopilot
Argo-CD Autopilot

Introduction New users to GitOps and Argo CD are not often sure how they should structure their repos, add applications, promote apps across environme

Jan 6, 2023
Hera is a Python framework for constructing and submitting Argo Workflows.

Hera is an Argo Workflows Python SDK. Hera aims to make workflow construction and submission easy and accessible to everyone! Hera abstracts away workflow setup details while still maintaining a consistent vocabulary with Argo Workflows.

Dec 31, 2022
A series of controllers for configuring namespaces to accomodate Argo

argo-controller A series of controllers for configuring namespaces to accomodate Argo. ArgoCD TBD Argo Workflows Make a service account in every names

Jan 4, 2022
This action prints "true" if image is required to update based on the base image update.

container-image-updater This action prints "true" if image is required to update based on the base image update. Inputs Name Type Description base-ima

Apr 15, 2022
Automatic-Update-Launcher - A general purpose updater for updating program binaries when update folder exists
Automatic-Update-Launcher - A general purpose updater for updating program binaries when update folder exists

Automatic Update Launcher A general purpose updater for updating (web) applicati

Jun 27, 2022
Argo Rollout visualization in Argo CD Web UI
Argo Rollout visualization in Argo CD Web UI

Rollout Extension The project introduces the Argo Rollout dashboard into the Argo CD Web UI. Quick Start Install Argo CD and Argo CD Extensions Contro

Dec 29, 2022
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.
Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes.

What is Argo Workflows? Argo Workflows is an open source container-native workflow engine for orchestrating parallel jobs on Kubernetes. Argo Workflow

Dec 10, 2021
go-fastdfs 是一个简单的分布式文件系统(私有云存储),具有无中心、高性能,高可靠,免维护等优点,支持断点续传,分块上传,小文件合并,自动同步,自动修复。Go-fastdfs is a simple distributed file system (private cloud storage), with no center, high performance, high reliability, maintenance free and other advantages, support breakpoint continuation, block upload, small file merge, automatic synchronization, automatic repair.(similar fastdfs).
go-fastdfs 是一个简单的分布式文件系统(私有云存储),具有无中心、高性能,高可靠,免维护等优点,支持断点续传,分块上传,小文件合并,自动同步,自动修复。Go-fastdfs is a simple distributed file system (private cloud storage), with no center, high performance, high reliability, maintenance free and other advantages, support breakpoint continuation, block upload, small file merge, automatic synchronization, automatic repair.(similar fastdfs).

中文 English 愿景:为用户提供最简单、可靠、高效的分布式文件系统。 go-fastdfs是一个基于http协议的分布式文件系统,它基于大道至简的设计理念,一切从简设计,使得它的运维及扩展变得更加简单,它具有高性能、高可靠、无中心、免维护等优点。 大家担心的是这么简单的文件系统,靠不靠谱,可不

Jan 8, 2023
A simple daemon which will watch files on your filesystem, mirror them to MFS, automatically update related pins, and update related IPNS keys.
A simple daemon which will watch files on your filesystem, mirror them to MFS, automatically update related pins, and update related IPNS keys.

ipfs-sync is a simple daemon which will watch files on your filesystem, mirror them to MFS, automatically update related pins, and update related IPNS keys, so you can always access your directories from the same address. You can use it to sync your documents, photos, videos, or even a website!

Dec 30, 2022
Image - This repository holds supplementary Go image librariesThis repository holds supplementary Go image libraries

Go Images This repository holds supplementary Go image libraries. Download/Insta

Jan 5, 2022
Testcontainers is a Golang library that providing a friendly API to run Docker container. It is designed to create runtime environment to use during your automatic tests.

When I was working on a Zipkin PR I discovered a nice Java library called Testcontainers. It provides an easy and clean API over the go docker sdk to

Jan 7, 2023
A Go-language library for the automatic generation of image collages.

CollageCreator is a Go-language library for the automatic generation of image collages.

Jan 29, 2022
Triggers an update to a Koyeb app service to re-deploy the latest docker image

Triggers an update to a Koyeb app service to re-deploy the latest docker image

May 5, 2021
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below
Automating Kubernetes Rollouts with Argo and Prometheus. Checkout the demo URL below

observe-argo-rollout Demo for Automating and Monitoring Kubernetes Rollouts with Argo and Prometheus Performing Demo The demo can be found on Katacoda

Nov 16, 2022
A plugin for argo which behaves like I'd like

argocd-lovely-plugin An ArgoCD plugin to perform various manipulations in a sensible order to ultimately output YAML for Argo CD to put into your clus

Dec 27, 2022