[suhlig]

Not sure how your current builds look like, but I tend not having to deal with containers per se. All they force you to do is be explicit about the build‘s dependencies, which I think is a useful thing.

My approach for migrating existing builds to Concourse is to start with a stock image (alpine or ubuntu), and gradually add things that are missing (`fly execute` is a big help for that).

Once I have a successful build, I extract the prerequisites into a task image (but that really is an optimization).

[shci]

That seems like a good approach when you have only a few pipelines. Unfortunately we have roughly 1000 pipelines/repos that all our our somewhat custom tooling that spawns up more docker containers with various volume mounts. For better or worse we're stuck with that for now, and we don't really have the capacity or desire to migrate all these projects to a completely new way of doing things.

So ideally the worker would just run commands on the worker host directly (no containers) and lets the containerization up to the executed jobs themselves. I'm not sure that's possible with Concourse (it looks like it does that for windows+darwin, but not on linux).

[suhlig]

> run commands on the worker host directly

I‘d think that Concourse is not the best fit for this requirement.