Replies: 1 comment
-
At the moment, this is probably best described in this section: https://kargo.akuity.io/concepts#promotion-mechanisms With additional details available here: https://doc.crds.dev/github.com/akuity/kargo/kargo.akuity.io/Stage/[email protected] Docs are very much still WIP.
As noted in the first of the two links above, some modifications to an Argo CD App are possible. Some possibilities are updating I am actually a bit confused as to when an Argo CD App's If it helps to clear up any confusion, typical use of Kargo looks like this:
Throughout the process, apps never get mutated except for what's necessary to force a sync/refresh. All of this works fine with monorepos. Kargo has some difficulties with monorepos currently, but I don't think your question touches on it. Anticipating that you'll want to know more about what the real difficulties of monorepos with Kargo are: If you have, as you say, 500 apps, changes to any one of their manifests in that monorepo result in new freight from any/all warehouses subscribed to it. So, if you have 500 pipelines and you update manifests relevant to one, then 499 of your pipelines will see a new piece of freight that, to them, really does not represent new state. #1270 is an existing issue that addresses this. #1477 is a proposed solution, but it hasn't been reviewed yet. |
Beta Was this translation helpful? Give feedback.
-
I'm evaluating Kargo as a replacement for image-updater, I know that Kargo does a lot more than image updates and that's also desired :)
I couldn't find documentation about how Kargo updates manifest when new images detected, does it write back the new image tags to
source.repoURL
of an Argo CD app? and if yes, does it handle git write safety in case of a mono repository? e.g. 500 Argo CD apps with samesource.repoURL
.Image updater has this issue that causes slow git write-back that gets worse as new apps are added to a mono repository.
Beta Was this translation helpful? Give feedback.
All reactions