#pre-commit dagger functions

1 messages · Page 1 of 1 (latest)

deft bobcat
#

actually deployed manifests and their corresponding source manifests are in-sync in the same commit

That sounds like a CD process. Don't mean to put your process into question, but yeah, why would you want CD-like things to happen pre-commit?

copper cave
#

it's a very opinionated implementation of the rendered manifests pattern for CD

#

in this case doing it within the same commit helps keep track of how source changes (i.e. from helm charts, jsonnet evaluations, kustomize patches) actually affect the rendered manifests

#

generally it's easier to audit

#

sort of like vendoring in your golang dependencies w/ go mod vendor

#

i'm using kustomize w/ some tooling so it can act as a build pipeline of sorts

#

once the manifests have been built/rendered to the builds/ directory, the actual CD solution (Argo CD in this case) only has the job of needing to synchronize what is described in Git as-is

#

so it also reduces a certain level of runtime uncertainty (not doing rendering in production)

deft bobcat
#

Unfortunately, I'm still unclear of your process needs, but I guess to answer your question, you can take parts of your pre-commit process and Daggerize them. You can start with just a part, maybe an easy one, then continue to do more from there. That's one of the cool things about Dagger. It can be incrementally utilized. 🙂

#

Whatever work you think can and should be parallelized, you can also control in your functions.

copper cave
#

ok, i'll try to take a swing at it, and if i have any issues i'll come back

#

i think trying to run kustomize will be interesting because KRM function invokation generally requires access to the docker command, does dagger support nested containers?

deft bobcat
#

I'm just reading about KRM functions. It sounds almost like Dagger functions, just very specific to Kustomize deployments. And yes, you could do DinD with Dagger.