I'm kind of using Garden as a replacement for manually scripting builds in either CI/CD scripts (i.e. Gitlab yaml) or in my Dockerfiles. I like being able to run the same thing locally and in CI as it makes the whole cycle much faster; and I like writing the script outside of the Dockerfile since its much easier to debug failing builds when its outside of the Dockerfile and I have to deal less with injecting tokens/keys etc. which is a PITA with docker (and different if you use

docker build

locally, and kaniko remotely). My goal is that I want an action to download/clone another repo, run (in effect)

make build

, and then have the outputs be available to other build tasks in my garden graph. I've run into a couple dead-ends so far though: 1. I tried just using "Build exec", which works if you don't sandbox anything which would be the more desirable way of working. Furthermore, this is not not ideal for running in CI and doesn't work in most cases. First, my CI runner is using the

gardendev/garden-gcloud

image which is good for running garden, but not so much for my own toolchain and may actually be incompatible (for instance this image is on alpine). I could make my own image but then it would be a weird hybrid and hard to maintain. Without that concern it would be better just to run exactly the same build container locally and in CI. 2. So I tried running the builds inside of a Pod in the cluster (whether that is local minikube or remote GKE). The problem here is that there is no Build type for running in an exec-like command in a pod (like

kubernertes-pod

for the Run action type). Using Run kubernetes-pod works, but the semantics around passing data between actions is only really set up for Build action types. I can output an artifact but AFAIK there is no good way to get this into the Build container workspace. So I think my feature request would be Build types for kubernetes-pod and kubernetes-exec. Would this be a difficult thing to add?

Hey @orange-ability-1812 I have a whole bunch of questions for you so bear with me: 1. Reading your first paragraph I'm thinking he's talking about Workflows! But I checked and you're already aware of their existence. You go on to mention a few things that might not be a fit for them but for what it's worth we do support using outputs from previous steps just in case you weren't already aware. If so, where do they fall apart for you? https://docs.garden.io/using-garden/workflows#step-outputs 2. I wonder why we don't publish buster builds for the cloud providers like we do for the standard

garden

image? I will ask for @big-spring-14945's help here since he's the genius behind those.

> we do support using outputs from previous steps just in case you weren't already aware. If so, where do they fall apart for you?

@orange-ability-1812 only the quote part came through for me

Ya sorry got involved in something trying to edit 😛 I will respond

Great! Let's start with the feature request. I will make a feature request for the Buster-flavored distros if you want to submit one for the Build action 🙂 Steffen is on vacation until Monday so we'll need to sit tight on a response until then