Support FROM <path>

[tt]

Other issues (in particular the proposed INCLUDE instruction #12749) have suggested ways to avoid repetition and I too have an idea.

If the FROM instruction was extended to support a path, base images can be built on demand.

Whereas the INCLUDE instruction would effectively rebase layers onto a parent they weren't designed to work with, FROM <path> is merely a convenience in not having to first build a regular base image and then build the dependent image.

This will extend the utility of the FROM instruction but not add another top-level instruction to the syntax.

The path should probably start with ./ to signify that it's a path and not a reference to an image.

[friism]

👍

[rbuckland]

What about if the FROM was (perhaps in addition to ./ ) ..

file:// or http:// or https://

[thaJeztah]

Would the path point to a Dockerfile, or to a .tar file containing a base filesystem?

I know @duglin proposed using build-time args to support something similar, i.e.

ARG baseimage=ubuntu:14.04
FROM $baseimage

and docker build --build-arg baseimage=ubuntu:15.10 .

[duglin]

so many things we could do.... :-)

[fsoppelsa]

So I guess this could be useful only in dev, because how would this proposal of loading unverified .tars match with the latest security requirements?

[tt]

@thaJeztah, my proposal is pointing to a Dockerfile which is then build using the same build context. That means it doesn't circumvent security initiatives. Everything that normally applies to a build (e.g. caching) will still apply.

Say you have Dockerfile.base and Dockerfile in your directory. If the latter includes FROM ./Dockerfile.base and you execute docker build ., that implies docker build -f Dockerfile.base . (and parsing the FROM ./Dockerfile.base as being from the resulting image).

I'm not sure how build options would address the reuse.

[thaJeztah]

@fsoppelsa I asked, because that would be the same as is done for the base images:

FROM scratch
ADD foobar.tar.gz /

@tt I think a simple Makefile or shell script would be able to give you that, i.e. "Build base image, then build the image I build on top".

But agree with @duglin, there are many possible options, point is we cannot make changes at this point, because there's currently a moratorium in place on the Dockerfile syntax, pending the refactor of the "builder" to move it to the client (which would allow custom builders as well). See; https://github.com/docker/docker/blob/master/ROADMAP.md#22-dockerfile-syntax

[tt]

@thaJeztah, yes, it's certainly possible but it's something a lot of users will need to maintain for themselves. That's also repetition.

I didn't open this anticipating it to be implemented today, though, so I'm fine having more discussion to figure out if this solve the need of others and arrive at a design that could eventually be implemented when the moratorium is lifted.

[JanJakes]

👍 This is the best, simplest, and most elegant of all the Dockerfile extensibility solutions proposed.

What is the timeline on unfreezing the Dockerfile syntax? It seems many great ideas get refused just because of the syntax freeze.

[oszi]

+1 for build-time args in the FROM instruction!

Using a path does not appeal to me:
Can/should it point to a place outside of the build's context?
What would a built base image be named?
How is it better than a simple COPY base / for the first instruction?

[thaJeztah]

Also see #4954

[rajivbhati12]

I see it kind of tricky because it impact the basic build principle of dockfile;
meaning:- every step of dockerfile execute in its own container and get save as a temp image for next step; with this thought; for first line to execute it has be static.
Unless we update FROM to perform extra step something like: if imagename[:tag] not found and appears to be more like variable then interpret it as variable

BTW; I am one add to people in queue waiting or this feature, as this can make CI look clean and not hacky
So, are there plans to enable this feature?

[tt]

I still think that this would be a great addition but with multi-stage builds and the ability to set a target build stage, you can now accomplish the same with a single Dockerfile.