#CI to trigger CD
haughty cloak
In my experience committing a config like that doesn't really give the benefits that config-as-code is meant for (the tanka config in this case). I'm not familiar with tanka specifically, but what I've done in general for this kind of flow is:
- all builds in CI create "releasable artifacts", which in this case sounds like it would be an image
- rather than committing a config with a ref to this image, either update the dev cluster over an API to use this image if possible, or template out the config and send it
Basically, is anything really accomplished by committing the updated config? From an event tracking point of view, it's basically just proof that the build happened, which is already evidenced by the CI run. If there's another way to tell the dev cluster it needs to update, just do that directly
languid canyon
In my experience committing a config like that doesn't really give the benefits ...
the whole gitops movement is coming for you Kyle 🤣
FWIW we do that ourselves for our own internal API CI. We build the app, we publish the docker image and then we update some k8s manifests which we re-commit to the repo so argo can pick them up
@tawny merlin I guess the main reason this is not a core primivite in Dagger is because even a though a simple git push might seem simple, git servers have a lot of caveats around how the git client needs to be configured in order to push to a repo. That's mostly why moduels exist, so you can grab a re-usable module and make it work for your own use-case.
tawny merlin
Sorry, I just noticed this thread here!