Considerations for mono repository

[mubarak-j]

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 same source.repoURL.

Image updater has this issue that causes slow git write-back that gets worse as new apps are added to a mono repository.

[krancour]

I couldn't find documentation about how Kargo updates manifest when new images detected

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.

---

does it write back the new image tags to source.repoURL of an Argo CD app

As noted in the first of the two links above, some modifications to an Argo CD App are possible. Some possibilities are updating source.targetRevision, updating Kustomize or Helm params, or merely forcing a refresh and sync (technically these aren't gitops because part of the "state of the world" lives in your Application resources instead of in a repo), but there is no option for updating source.repoURL...

I am actually a bit confused as to when an Argo CD App's source.repoURL would ever need to be updated, and for that matter, I'm unaware of any valid use where that field ever points to an image. I'm only aware of it ever pointing at a git repo or Helm chart repo.

---

If it helps to clear up any confusion, typical use of Kargo looks like this:

• Warehouse subscribes to a git repo and one or more image repos
  • Changes to any repo (image or git) result in new freight
• Promotion of a piece of freight to a given stage executes that stage's promotion mechanisms. The most common promotion mechanisms would:
  • Mash the images in the freight up with the manifests in the git repo -- specifically those from the commit that is also referenced by the freight
  • Write the result to a stage-specific branch, which you can just think of as storage

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.

[krancour]

Closing this, but noting that in the long interval since the last post in this convo, Kargo has gotten significantly better at dealing with monorepos, mainly through the ability of a Warehouse to subscribe only to new commits from a repo affecting/not affecting specific paths within the repo.