Local only rendering?

[danijam]

I think I got the wrong impression from my first encounter with kargo-render at KubeCon. I have a use case which I want to know if kargo-render can do now or could do in the future?

I want to be able to execute a cli tool locally (or in a CI pipeline) that takes a helm chart and its values state as input and then spits out the rendered results of that to a filesystem.

I know helm template can do this but I would like the end result to have each resource in it's own file with good naming convention or directory structure and the resource to not have the helm labels/annotations or have any namespace metadata.

I'd hoped I could use kargo-render for this job. Anyone got any suggestions on moving the rendering of helm charts upstream (with respect to Argo) with better control than what helm template gives.

[krancour]

For some time now, the configManagement field of Kargo Render's appConfigs looks like a subset of an Argo CD ApplicationSource, and in fact, Kargo Render uses the Argo CD repo server (in process, as a library) to do its rendering. So if Argo CD could render what you've got just-in-time for deployment, Kargo Render can do the same rendering ahead of time. (Unless there are CMPs involved. We haven't gotten that figured out yet.)

I want to be able to execute a cli tool locally

We don't publish the Kargo Render CLI as a standalone. It requires git, kustomize, and helm binaries, so to ensure those dependencies are satisfied (and with compatible versions no less), we ship the CLI along with those other binaries in Kargo Render's Docker image. The docs cover how to use it: https://kargo-render.akuity.io/how-to-guides/docker-image

and then spits out the rendered results of that to a filesystem

Historically, Kargo Render clones your repo and writes back out to it and doesn't use the local file system (the container's file system, really) for anything other than a temporary workspace.

As of somewhat recently there are new flags on the CLI that allow reading from an already-cloned repo that is presumed to already have the desired source commit checked out. Also as of somewhat recently, the results of the rendering can be written to the local file system.

Aside: We added these because this is how Kargo itself interacts with Kargo Render these days. Kargo handles all the git cloning, checking out, committing, pushing, etc. and only asks Kargo Render to pick up what's in a particular location on the file system and render it out to another location.

I don't believe these newer flags are documented anywhere just yet, but the help is decent:

docker run -it ghcr.io/akuity/kargo-render:v0.1.0-rc.39 -h

Do remember that because it's running in a container, if you want to read from or write to the host's local file system, you'll actually have to mount volumes accordingly.

or in a CI pipeline

GitHub Actions has been supported for quite some time:

https://kargo-render.akuity.io/how-to-guides/github-actions

If you wish to integrate with other CI systems, since most support containers, you can achieve that just by using the Docker image as described above.

I would like the end result to have each resource in it's own file with good naming convention or directory structure

This is actually the default behavior. It's what happens unless you opt out of it.

https://kargo-render.akuity.io/how-to-guides/configuration#combining-manifests

and the resource to not have the helm labels/annotations or have any namespace metadata

The results will look just as if Argo CD had rendered them. As I mentioned -- it's using all the same code. Off the top of my head I do not recall if that includes or excludes those labels and annotations.

Bottom line: Kargo Render should be capable of doing what Argo CD does, but doing it where and when you want instead of just-in-time for deployment.