Hello! We're a small team using Garden to manage and deploy a set of AI workloads and services on clusters in different environments, and it's working really well for us. We have until now used a garden build+test+deploy workflow for all our environments (dev, test and prod) using container Build, container Test and kubernetes Deploy actions. However, we want to implement a GitOps approach for our prod environment, in which Garden is only responsible for building images and rendering k8s manifests, after which the manifests should be handed over to a GitOps tool (we're trying out the Pulumi Kubernetes Operator at the moment). But we're not quite sure what is the most natural way to use Garden to just render and output the k8s manifests without deploying them. I can think of a few hacky ways, but since I imagine this might be a reasonably common use case, I'm wondering if I'm missing something and if there is one or more "natural" patterns for such a workflow using Garden.

Hi @abundant-hydrogen-87873! Apologies for the delay: I've been on vacation and just now catching up with all the open posts here. Have you seen https://garden.io/blog/argo-cd-helm-charts ? It addresses almost all your requirements except for rendering manifests out. If you use a Helm Library Chart that should solve for that part. I recently updated an old blog post I did on migrating from Docker Compose to Helm with Garden. If you scroll down to the Helm section that tells you everything you need to know to try that approach https://garden.io/blog/migrating-docker-compose-to-kubernetes But happy to keep discussing more and find a method that really works for you. Also super happy to jump on a video call with your team and talk ideas 💡

Thanks a lot for the advice, @quaint-dress-831! I'll investigate the Helm approach and see if it works for us. Really appreciate the offer of getting on a call as well, thank you! I don't think that's necessary right now, but we might take you up on the offer in the future if it still stands. The team is quite invested in Garden for our CI/CD pipeline, so it's likely we'll have more questions in the future. For now, I do think it would be really neat and useful if it was easy to selectively retrieve and use the rendered outputs from the Garden graph (

garden get config

does this, but it requires resolving the entire project which is far from ideal in our setup). We find the combination of Garden templating in general and ConfigTemplates to be super convenient for reducing boilerplate in our repo; we actually use a single Garden project with standardized templates for all of the different services on our clusters. Having first-class easy access to rendered, raw outputs from Deploy action types to be passed on to some other tool would be a very convenient way to integrate Garden with other continuous deployment tools, since Garden itself does not provide functionality similar to ArgoCD, Flux, and/or the Pulumi Kubernetes Operator. I think my ideal approach would be to use Garden for end-to-end builds, tests and deploys in our dev and test environments, but in prod I would use Garden only to build and render the manifests and upload them to a cloud bucket (we're on Azure, so Azure Blob Storage), and then point a Flux source (which is supported by the Pulumi Kubernetes Operator) to this location. This would ensure that the desired state of our cluster is stored and always maintained - even if the cluster itself is taken down - without having to run

garden deploy

. To me, this type of use case seems fairly reasonable, so I'm wondering if it makes sense for me to put the required rendering functionality in as a feature request? What do you think?

> The team is quite invested in Garden for our CI/CD pipeline, so it's likely we'll have more questions in the future. Happy to answer any and all you may have on your Garden journey 🧑‍🌾 > Having first-class easy access to rendered, raw outputs from Deploy action types to be passed on to some other tool would be a very convenient way to integrate Garden with other continuous deployment tools Yes, this does sound like an excellent feature request. Provided Helm Library Charts are not right-fit for you (I must admit I am crazy about them as a pluggable framework for going images->manifest) I'd consider just directly pasting what you wrote above into a feature request and we'll take it from there 🙂

Excellent, thanks again, @quaint-dress-831! I'll definitely dig into the Helm approach; although we use Helm Charts for several applications running on our clusters I'm not very familiar with its capabilities, so it's a good opportunity to learn something new in any case. I might get back with the feature request on GitHub if it still seems relevant for solving our problem!