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?

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

  • Defined parameters in Application getting overwritten

    Defined parameters in Application getting overwritten

    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

  • Image Updater reverts image to old tag with latest strategy

    Image Updater reverts image to old tag with latest strategy

    Describe the bug I am testing image-updater plugin with ArgoCD for our CD solution, I have used following annotations on my Argo app

        argocd-image-updater.argoproj.io/image-list: app=kahootali/nginx
        argocd-image-updater.argoproj.io/app.update-strategy: latest
        argocd-image-updater.argoproj.io/app.allow-tags: regexp:^[0-9]{6}-[0-9]{6}_RC$
    

    I am using my nginx image based on default nginx:alpine image just for testing purposes...

    https://hub.docker.com/r/kahootali/nginx/tags

    The tags are using date & time for understanding which image was built when.

    At first, I used the image tag 221506-164030 the plugin updated the image to 222406-162230_RC and pushed to git which is fine, but then I built the new image 222406-163830 and updated git manually with this new tag but the plugin again reverted to 222406-162230_RC which shouldn't be the case as the one I updated manually was built later than the one with _RC tag..

    Expected behavior Argocd-image-updater shouldn't have updated the image to the previous tag as it matches the regex but should have checked whether the timestamp is greater as well , as the new tag can be a hotfix and I need to update it urgently..

    Version

    quay.io/argoprojlabs/argocd-image-updater:v0.12.0
    

    Logs Used debug level logs

    time="2022-06-24T11:45:44Z" level=debug msg="Considering this image for update" alias=app application=argotestapp-development image_name=kahootali/nginx image_tag=222406-163830 registry=
    time="2022-06-24T11:45:44Z" level=debug msg="Using no version constraint when looking for a new tag" alias=app application=argotestapp-development image_name=kahootali/nginx image_tag=222406-163830 registry=
    time="2022-06-24T11:45:45Z" level=debug msg="Cache hit for kahootali/nginx:222406-162230_RC" alias=app application=argotestapp-development image_name=kahootali/nginx image_tag=222406-163830 registry=
    time="2022-06-24T11:45:45Z" level=debug msg="found 1 from 1 tags eligible for consideration" image="kahootali/nginx:222406-163830"
    time="2022-06-24T11:45:45Z" level=info msg="Setting new image to kahootali/nginx:222406-162230_RC" alias=app application=argotestapp-development image_name=kahootali/nginx image_tag=222406-163830 registry=
    time="2022-06-24T11:45:45Z" level=debug msg="target parameters: image-spec= image-name=application.deployment.image.repository, image-tag=application.deployment.image.tag" application=argotestapp-development image=kahootali/nginx
    time="2022-06-24T11:45:45Z" level=info msg="Successfully updated image 'kahootali/nginx:222406-163830' to 'kahootali/nginx:222406-162230_RC', but pending spec update (dry run=false)" alias=app application=argotestapp-development image_name=kahootali/nginx image_tag=222406-163830 registry=
    
  • Image Updater shouldn't update Images which are reverted manually

    Image Updater shouldn't update Images which are reverted manually

    Is your feature request related to a problem? Please describe. I am using ArgoCD image updater with the following annotation to match my image tags

        argocd-image-updater.argoproj.io/app.update-strategy: latest
        argocd-image-updater.argoproj.io/app.allow-tags: regexp: MY_REGEX
    

    and image-updater works fine, and updates the image and pushes back to github, but if there is an issue with new image and I or other developers need to revert to an older version, then issue arises. As I update github with old version manually but image-updater again updates to newer version, there should be a way of controlling this...

    I know of ignore-tags option but that doesn't seem viable in our case as the developers cant change Argocd apps, rather they know the helm values only.

    Describe the solution you'd like Somehow check if the image is manually overriden by a commit in git after image-updater's commit, then dont auto-update it.

  • chore(deps): bump github.com/argoproj/argo-cd/v2 from 2.2.7 to 2.2.10

    chore(deps): bump github.com/argoproj/argo-cd/v2 from 2.2.7 to 2.2.10

    Bumps github.com/argoproj/argo-cd/v2 from 2.2.7 to 2.2.10.

    Release notes

    Sourced from github.com/argoproj/argo-cd/v2's releases.

    v2.2.10

    Quick Start

    Non-HA:

    kubectl create namespace argocd
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.2.10/manifests/install.yaml
    

    HA:

    kubectl create namespace argocd
    kubectl apply -n argocd -f https://raw.githubusercontent.com/argoproj/argo-cd/v2.2.10/manifests/ha/install.yaml
    

    Security fixes

    Potentially-breaking changes

    From the GHSA-2m7h-86qq-fp4v description:

    The patch introduces a new reposerver.max.combined.directory.manifests.size config parameter, which you should tune before upgrading in production. It caps the maximum total file size of .yaml/.yml/.json files in directory-type (raw manifest) Applications. The default max is 10M per Application. This max is designed to keep any single app from consuming more than 3G of memory in the repo-server (manifests consume more space in memory than on disk). The 300x ratio assumes a maliciously-crafted manifest file. If you only want to protect against accidental excessive memory use, it is probably safe to use a smaller ratio.

    If your organization uses directory-type Applications with very many manifests or very large manifests then check the size of those manifests and tune the config parameter before deploying this change to production. When testing, make sure to do a "hard refresh" in either the CLI or UI to test your directory-type App. That will make sure you're using the new max logic instead of relying on cached manifest responses from Redis.

    Bug fixes

    Other

    • test: directory app manifest generation (#9503)
    • test: fix erroneous test change
    • chore: eliminate go-mpatch dependency (#9045)
    • chore: Make unit tests run on platforms other than amd64 (#8995)
    • chore: remove obsolete repo-server unit test (#9559)
    • chore: upgrade golangci-lint to v1.46.2 (#9448)
    • chore: update golangci-lint (#8988)

    v2.2.9

    Quick Start

    Non-HA:

    ... (truncated)

    Commits
    • 8db0e57 Bump version to 2.2.10
    • 80a10d4 Bump version to 2.2.10
    • 29521a9 chore: fix docs gen
    • 58cccd5 Merge pull request from GHSA-jhqp-vf4w-rpwq
    • 265a644 Merge pull request from GHSA-q4w5-4gq2-98vm
    • 1fe9574 Merge pull request from GHSA-2m7h-86qq-fp4v
    • 05e9079 Merge pull request from GHSA-h4w9-6x78-8vrj
    • fd42ba7 fix: missing Helm params (#9565) (#9566)
    • 4040dee test: directory app manifest generation (#9503)
    • 845cfde test: fix erroneous test change
    • Additional commits viewable in compare view

    Dependabot compatibility score

    Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.


    Dependabot commands and options

    You can trigger Dependabot actions by commenting on this PR:

    • @dependabot rebase will rebase this PR
    • @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
    • @dependabot merge will merge this PR after your CI passes on it
    • @dependabot squash and merge will squash and merge this PR after your CI passes on it
    • @dependabot cancel merge will cancel a previously requested merge and block automerging
    • @dependabot reopen will reopen this PR if it is closed
    • @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
    • @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
    • @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
    • @dependabot use these labels will set the current labels as the default for future PRs for this repo and language
    • @dependabot use these reviewers will set the current reviewers as the default for future PRs for this repo and language
    • @dependabot use these assignees will set the current assignees as the default for future PRs for this repo and language
    • @dependabot use this milestone will set the current milestone as the default for future PRs for this repo and language

    You can disable automated security fix PRs for this repo from the Security Alerts page.

  • Remove git write-back file .argocd-source-{application}.yaml from git when Application is removed from ArgoCD

    Remove git write-back file .argocd-source-{application}.yaml from git when Application is removed from ArgoCD

    Is your feature request related to a problem? Please describe. When an ArgoCD Application gets removed the corresponding git write-back .argocd-source-{application}.yaml file should also be removed from git.

    Describe the solution you'd like Image updater should push the deletion of .argocd-source-{application}.yaml files when Application is removed from ArgoCD.

    Describe alternatives you've considered I am manually deleting these files but I am afraid that I will delete a file that still belongs to a live Application.

  • Container Image CVEs - v0.12

    Container Image CVEs - v0.12

    There are critical CVEs in the argocd-image-updater container.

    Image tagged v0.12.0. Most of these have been fixed; see here and here

    image


    Hello, Our security team is asking us to get these CVEs remediated. These issues are not with argocd-image-updater itself, but rather the base image. I am reporting this here based on this line in the security policy:

    Please report issues with our container image directly on the GitHub tracker if the issue has already been assigned a CVE.

    Is there any chance of a new release for version v0.12.0 with an updated base image?

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

Jun 25, 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.

Jun 29, 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

Jun 17, 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

Jun 29, 2022
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.

Jun 30, 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.

Jun 29, 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

Jul 2, 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协议的分布式文件系统,它基于大道至简的设计理念,一切从简设计,使得它的运维及扩展变得更加简单,它具有高性能、高可靠、无中心、免维护等优点。 大家担心的是这么简单的文件系统,靠不靠谱,可不

Jun 30, 2022
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!

Jun 14, 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

Jun 26, 2022
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

Jun 15, 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

Jul 1, 2022