Open cpuguy83 opened 2 years ago
I don't really get the first example with COPY --from=tmpl
but the second one looks quite similar to this old proposal https://github.com/moby/moby/issues/32100
FWIW this sounds similar to Earthly's User Defined Command concept.
Or, you could use dagger.io to make a composable Dockerfile. With dagger.io, you could maintain the shared elements independently and compose Dockerfiles.
Definitely understand that dagger supports this, the idea though is to enable this Dockerfile.
I currently have a project that requires build 6 different components across 7 distros with 3 CPU architectures. In this project there ends up being a ton of duplication in Dockerfiles. Making changes to anything means I really need to make changes to everything. A bug in a change means a bug everywhere and a change everywhere.
Changes at this scale (which isn't even that large) are extremely difficult to keep track of, be it in one big Dockerfile or across many Dockerfiles (either way is pretty much equal IME). Where I want some uniformity there's always some fat-fingering, things put in Line X when I meant to put in line X+1... basically lots of room for human error.
One potential solution that occurred to me is something along the lines of a new instruction called
TEMPLATE
(let the bike-shedding commence).TEMPLATE
would be treated pretty much like aFROM
, the only difference is the context is determined by where it is called from and the stage itself is not cached except within the calling context which can be called multiple times from within different contexts.As an example
Now, this is kind of a weird example because the template is already being executed with the filesystem in the
builder
stage. Perhaps we need a way to execute a template without having to explicitly copy from it.Perhaps one could specify a path to a template, where that path would be within the build context:
or
Can a template include another template? One may question why so meta, but in the end I don't see why it wouldn't work. It should just be another dependency as far as buildkit would be concerned.
What's stops someone from trying to run
apt-get
in abusybox
container? Nothing. Same as it is today. You'll get an error from the system thatapt-get
doesn't exist.This is one of those things that can be easily abused that probably most people don't need but could really soothe the pain of medium to large scale projects.