abundant-hydrogen-8787308/12/2023, 12:14 PM
quaint-dress-83108/14/2023, 1:46 PM
abundant-hydrogen-8787308/15/2023, 9:50 AM
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 get config
. 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?
quaint-dress-83108/15/2023, 11:40 AM
abundant-hydrogen-8787308/15/2023, 1:48 PM