https://garden.io logo
Join Discord
Powered by
We ve actually got an experimental
# 💻｜contributing
s
We've actually got an experimental 
garden plan
command on a branch somewhere! We'll be rolling this out in the coming months. That's essentially a dry-run deploy (with the added capability of rendering out e.g. Helm values with all Garden template strings fully resolved—making it a great fit for e.g. handing over to GitOps-based CD systems while using Garden's templating abilities).
b
Nice, seems like this is already in the pipeline then @icy-furniture-17516, this is beautiful! Thanks.
s
... @curved-intern-91221 and I wrote this during a hackathon last year, so we'll need to adapt it for Bonsai and do some wrapping up and documenting, but it should be relatively straightforward once we decide to prioritise it!
c
Yes, we have the changes from the hackaton in the branch: https://github.com/garden-io/garden/tree/plan-command
i
wow, nice!
adding @quaint-dress-831 as I mentioned this to him as well
q
@icy-furniture-17516 I've created this as a feature request in our GitHub: we'll keep you updated 🙂 https://github.com/garden-io/garden/issues/4658
i
Getting back to this thread if you don't mind, because I have a question. Not sure if you made any progress with this on a different branch, but I would be interested in the way this supposed to work.
The question is whether the plan command would be something that could dump kubernetes manifests to stdout or to a specific directory perhaps?
It would be a nice way to detach the source code and the actual deployment artifacts, so that we can version and ship these artifacts separately from the source.
The way I imagine this would work: - run 
garden publish
to build and push images to a registry - run 
garden plan
(or similar) that does not build anything but dumps k8s manifests with the previously built image references somewhere - hand it over to some gitops workflow, so that it can safely manage deployments no matter it has to roll something out or roll something back
The "dry-run deploy" thing, that @swift-garage-61180 mentioned would ideally do that, but I'm not sure if it would be the same as what I originally thought about when I was thinking of what "plan" should do. Actually it doesn't have to know anything about the previously applied manifests, that will be the job of the gitops tool.
Also, as far as I know garden does not support removing stuff that were deployed before, but that do not exist anymore in the modules
That's again something that the gitops tool can handle if it has the manifests
Long story short I just wanted to clarify, that the thing we primarily need is the dry-run thing with manifests instead of a nice "plan view" that could highlight changes
s
We haven't done any more work on the plan command since we first prototyped it, but the prototype did basically what you're describing: It creates fully materialized deployables (e.g. Kubernetes manifests or Helm charts with all Garden template strings resolved) and writes them into a local directory (which is also configurable). Separately, it also generates (and logs) diffs with the currently deployed resources. All that said, we'd need to find the time to prioritise wrapping it up (for one, it was written for 0.12, so there would be some refactoring to do to apply it on top of 0.13). Glad to hear you're interested in it, would be really cool to roll it out!
i
Could this work for container type actions or just for kubernetes?
Not a big deal if not I think, since we can keep the container builds and write kubernetes deploy actions separately
s
We had already implemented this for 
container
, 
helm
and 
kubernetes
services (which are now Deploys in 0.13).
i
I've tried to merge that experimental branch onto 0.12 and would like to give it a try to see what it does. Is there a containerized way to build garden or I should go with what is described in the contributing guide and try to build on my local machine?
b
Yes, you can follow the contributing guide to get the binary and then just do an alias like 
alias gdev="path-to-binary"
i
Update: I haven't been able to get to the bottom of a build issue when I was trying to build garden locally, but then I ran out of time. Also, next day I realized that even if I could generate k8s manifests, I would still need to transform them so that I can add templating to it, for example to be able to set image names and so on. So I chose to refactor all of our container and kubernetes modules into a single chart with enable/disable flags to control the component I want to activate for a given module
(I wanted a single chart because it's much easier to manage)
so I have a base chart module, that has all the components disabled in it, and when I define a module, I can use this chart as a base and enable the single component I need
I have 8 modules (1/2-1/2 container-kubernetes) and took me a day to refactor
we have some other modules as well, that we didn't want to include in this chart, used for demo contents and so on, but those are still fine in garden
I love the way we could solve this, because now we can have an image build and ship it along with the chart as a release artifact
I forgot to mention, that we are still looking for the "plan" functionality for the dev/demo environments that we find easier to deploy manually for now, but for a production setup, the aggregated helm chart seems to be a better/simpler solution for multiple reasons
PreviousNext
Powered by