Skip to content

Add Argo Image Updater - #370

Merged
IanKWatts merged 4 commits into
mainfrom
image_updater
Sep 1, 2026
Merged

Add Argo Image Updater#370
IanKWatts merged 4 commits into
mainfrom
image_updater

Conversation

@IanKWatts

Copy link
Copy Markdown
Contributor

Add a new document to the automation section for the new Argo CD image updater feature.

@mtspn mtspn left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just one small suggestion:

```

### Example 2 - Kustomize
In this example, a Kustomize app uses the 'latest' tag. Because the tag does not change, the image updater uses the SHA checksum to look for changes and will apply the checksum value as the image tag in your live deployment.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just wondering if it's possible to add some extra context here, not sure if my suggestion is ideal but this or something similar? suggestion In this example, a Kustomize app uses the 'latest' tag. Because the tag does not change, the image updater uses the SHA checksum to look for changes and will apply the checksum value as the image tag in your live deployment. In the example below, when a new netshoot image is published with the latest tag, Argo CD Image Updater detects the updated image digest and triggers a redeployment of our application.

tag: "2.10.1"
```

The following ImageUpdater uses a 'newest-build' strategy, but also adds an 'allowTags' field to limit updates to the `2.10.x` pattern, so as new patch versions of 2.10 are released, they will be automatically applied by Argo CD, but it will not be updated to 2.11 or higher.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm a bit concerned about using allowTags this way, it'd be possible that say someone is using 2.10.9, with a new build they might be reverted back to 2.10.1 and potentially breaking the app. I think it's fine to use it as an example, but shall we mention that it's generally not a good idea to not specify an image tag?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, that is an edge case, but you make a valid point. 'newest-build' uses build date and allowTags is just a filter, so it would be better to change this example to use the 'semver' strategy, which would only select the highest version of a given pattern. I'll update this example.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ShellyXueHan I've updated this example to use the semver strategy. Thanks for your feedback.

@IanKWatts
IanKWatts requested a review from mtspn August 28, 2026 23:12
@IanKWatts
IanKWatts requested a review from ShellyXueHan August 31, 2026 16:45
@IanKWatts
IanKWatts merged commit f9ea251 into main Sep 1, 2026
3 checks passed
@IanKWatts
IanKWatts deleted the image_updater branch September 1, 2026 20:43
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants