You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
The update-strategy: latest leads to a situation which seems to make it difficult to support a rollback scenario.
Let's say your annotations are like this:
argocd-image-updater.argoproj.io/update-strategy: latest # Use the latest tag matching the filter below
argocd-image-updater.argoproj.io/allow-tags: regexp:^test- # Only allow tags that start with test-
argocd-image-updater.argoproj.io/image-list: hello-world=dockerregistry.com/hello-world
Let's say you build/push image tag AAA, then BBB, but you don't like BBB so you rollback and push image tag CCC. In our GitHub Actions based pipeline at least, the layers for CCC match AAA which are already cached, so they are not re-built.
argocd-image-updater then looks for the "latest built" image - which still is BBB. Not the "latest pushed" image.
Describe the solution you'd like
It'd be great if there was a way for the update strategy to use "latest PUSHED" vs just "latest built." This would be more intuitive to end-users of the CICD pipeline.
Describe alternatives you've considered
As currently constructed, it sems like we'd have to manually get rid of the annotations on the application and hardcode the AAA or CCC tag in the Application resource to use those to do a rollback in this scenario, or like use a build ARG in the Dockerfile to force build a new layer.
Additional context
Using the argocd update method currently. Our docker registry is AWS ECR.
The text was updated successfully, but these errors were encountered:
Is your feature request related to a problem? Please describe. The update-strategy: latest leads to a situation which seems to make it difficult to support a rollback scenario.
Let's say your annotations are like this:
argocd-image-updater.argoproj.io/update-strategy: latest # Use the latest tag matching the filter below
argocd-image-updater.argoproj.io/allow-tags: regexp:^test- # Only allow tags that start with test-
argocd-image-updater.argoproj.io/image-list: hello-world=dockerregistry.com/hello-world
Let's say you build/push image tag AAA, then BBB, but you don't like BBB so you rollback and push image tag CCC. In our GitHub Actions based pipeline at least, the layers for CCC match AAA which are already cached, so they are not re-built.
argocd-image-updater then looks for the "latest built" image - which still is BBB. Not the "latest pushed" image.
Describe the solution you'd like It'd be great if there was a way for the update strategy to use "latest PUSHED" vs just "latest built." This would be more intuitive to end-users of the CICD pipeline.
Describe alternatives you've considered As currently constructed, it sems like we'd have to manually get rid of the annotations on the application and hardcode the AAA or CCC tag in the Application resource to use those to do a rollback in this scenario, or like use a build ARG in the Dockerfile to force build a new layer.
Additional context Using the argocd update method currently. Our docker registry is AWS ECR.
Is your feature request related to a problem? Please describe.
The
update-strategy: latest
leads to a situation which seems to make it difficult to support a rollback scenario.Let's say your annotations are like this:
Let's say you build/push image tag AAA, then BBB, but you don't like BBB so you rollback and push image tag CCC. In our GitHub Actions based pipeline at least, the layers for CCC match AAA which are already cached, so they are not re-built.
argocd-image-updater then looks for the "latest built" image - which still is BBB. Not the "latest pushed" image.
Describe the solution you'd like
It'd be great if there was a way for the update strategy to use "latest PUSHED" vs just "latest built." This would be more intuitive to end-users of the CICD pipeline.
Describe alternatives you've considered
As currently constructed, it sems like we'd have to manually get rid of the annotations on the application and hardcode the AAA or CCC tag in the Application resource to use those to do a rollback in this scenario, or like use a build ARG in the Dockerfile to force build a new layer.
Additional context
Using the
argocd
update method currently. Our docker registry is AWS ECR.The text was updated successfully, but these errors were encountered: