Allow for Dockerfile to be named something else. #9707

duglin · 2014-12-17T13:41:42Z

This is a follow-on to #7995 and #7284.

This PR allows for the Dockerfile to be named something other than Dockerfile via a -f/--file option. Aside from the name/path of the Dockerfile being variable, nothing else should change from today's behavior. The location of the Dockerfile MUST be within the build context.

This PR contains the:

code changes
docs updates
testcases

Signed-off-by: Doug Davis dug@us.ibm.com

crosbymichael · 2014-12-17T18:00:57Z

@duglin you are so fast!

crosbymichael · 2014-12-17T18:07:06Z

api/client/commands.go

 			if err != nil {
 				return fmt.Errorf("Bad .dockerignore pattern: '%s', error: %s", pattern, err)
 			}
 			if ok {
-				return fmt.Errorf("Dockerfile was excluded by .dockerignore pattern '%s'", pattern)
+				return fmt.Errorf("Dockerfile(", *dockerfileName, "was excluded by .dockerignore pattern '%s'", pattern)


This looks kinda weird, can you please use the traditional printf format here?

cyphar · 2014-12-17T21:42:06Z

IMO, I don't like that the Dockerfiles use the root context. While it may make sense from a short-sighted end-user point of view, there's an issue regarding symmetry.

Specifically:

$ docker build -f dockerfiles/some-file
$ cd dockerfiles && docker build -f some-file

The above two lines are not synonymous, because the Dockerfiles are built in different contexts. This results in two (IMO not acceptable) side effects:

The above symmetry is broken. This means that the directory in which docker build is called is now important, despite having a flag that allows you to specify relative directories.
Dockerfiles now need to be context aware on a different level -- they need to care about where they are called from.

IMHO, Dockerfiles specified by the -f flag should be used as the root of the context, not applied to the root context of the docker run command.

Just my $0.02.

tianon · 2014-12-17T21:55:13Z

The "context" argument is still required, right?

duglin · 2014-12-17T21:59:32Z

@tianon yes I think that's a typo in his example.
So, let's say you do this (starting at the root of my build context on the cli):
cd foo
docker build -f myDockerfile ..

Right now this will fail because the CLI blindly passed the -f value to the daemon w/o taking into account that we're in "foo" and the daemon will look for myDockerfile in the root of the build context. IOW, the CLI really should convert "-f myDockerfile" to "-f foo/myDockerfile" before it sends it to the REST API so the daemon will find it.

@cyphar I think you're correct but let's see what other think before I change it.

duglin · 2014-12-17T22:00:47Z

@crosbymichael I fixed the errorf stuff you noticed.
@jfrazelle I got drone working. It turns out I had to name my containers as they were built. Go figure.

tianon · 2014-12-17T22:02:54Z

Cool, SGTM. I think the CLI would then also need to throw an error when
attempting to use a Dockerfile from outside the context.

ADD/COPY are also going to get a little confusing here. :)

duglin · 2014-12-17T22:03:42Z

@tianon yes, it already throws an error if -f (on the daemon) points to something outside of the context, but yes this will force an additional check on the CLI side.

cyphar · 2014-12-17T22:16:44Z

@tianon a little more confusing. The reason for the whole context beef is that Dockerfiles now will need to either reference things relative to the root context when ADD or COPYing (which means they must know where they should be called from, meaning you lose some level of predictability) or relative to the Dockerfile (which means you now have Dockerfiles that care where they are placed inside the repository).

Neither of those options sound favourable to me (also the above symmetry concerns are quite important IMO, and if we're going to add this new functionality we might as well get it right the first time :P).

crosbymichael · 2014-12-17T22:18:22Z

@cyphar but also, you don't have to use -f. The people who want this feature want more control and therefore must pay the portability cost that it comes with.

duglin · 2014-12-17T22:20:48Z

right, I think you should be able to put your dockerfile anywhere you want, but in the end any relative paths in there (e.g. on ADD/COPY) are relative to the context root. I think the docs are pretty clear on this already.

cyphar · 2014-12-17T22:27:53Z

@crosbymichael Surely they can place Dockerfile.prod, Dockerfile.test, etc in the root directory and call it a day with -f in the example? It's not just a portability thing (although that is an issue), it's a symmetry and consistency thing.

But idk, I might be acting far too idealistically for a feature like this.

duglin · 2014-12-17T22:29:19Z

@cyphar are you saying you don't think I should make your suggested change?
Seemed right to me.

cyphar · 2014-12-17T22:37:05Z

@duglin Nono, I think that the change should be made. I just thought I was the only one who thought that :P.

LK4D4 · 2014-12-17T22:37:39Z

I'm not sure about what we talking about, if context parameter is still necessary.

cyphar · 2014-12-17T22:41:27Z

@LK4D4 Oh, I completely forgot about the context parameter. That makes -f even weirder. Do you have to do this now:

$ docker build -f somedir/Dockerfile.magic somedir/

Or should it assume that you want the context to be somedir, unless you specify the context parameter?

LK4D4 · 2014-12-17T22:43:46Z

@cyphar Yes, you have to do this.

duglin · 2014-12-17T22:44:35Z

so I guess the question is:
should -f be relative to the current dir or to the root of the build context?
As an end user, my first reaction was to think it should be relative to the current dir. Your first example was the most compelling to me:
cd foo
docker build -f myDockerfile ..
it would be really odd to me to have to write:
docker build -f foo/myDockerfile ..

slafs · 2014-12-17T23:03:03Z

Just wanted to add that I think we have a potential backwards incompatible change here. Because having that kind of structure:

.
├── dockercontext
│   ├── Dockerfile
│   └── ...
├── Dockerfile
└── ...

and running docker build dockercontext/ (without -f option) could build different images on different versions of Docker. Right? Or am I missing something?

duglin · 2014-12-17T23:13:37Z

@slafs no it should not change that, if it does then I broke something :-)

thaJeztah · 2014-12-17T23:28:25Z

Hope I'm not messing up the discussion with this, but something I brought up in #7284; Should each Dockerfile also be able to have its own .dockerignore file?

My use case; being able to build multiple images (dev/prod) from the same context, but exclude some large files (or large amount of files) from the image that are not needed when building a dev image. Being able to exclude those files gives a huge speed gain when building the image.

crosbymichael · 2014-12-18T00:39:19Z

@duglin what you said here sounds like what we would expect as an end user "As an end user, my first reaction was to think it should be relative to the current dir."

We can go that route.

duglin · 2014-12-18T02:39:46Z

@thaJeztah if we did want to support multiple .dockerignores then I would think it could be done in a similar way to the -f option, so: -i/--ignore=file but I think that would be a new PR.

LK4D4 · 2015-01-06T18:33:05Z

@duglin need rebase :) sorry

duglin · 2015-01-06T19:20:16Z

@LK4D4 ok rebased

erikh · 2015-01-06T19:23:10Z

api/client/commands.go

+
+		if *dockerfileName == "" {
+			// No -f/--file was specified so use the default
+			origDockerfile = "Dockerfile"


can we make this a constant?

erikh · 2015-01-06T19:25:01Z

need the constant, otherwise LGTM

duglin · 2015-01-06T20:11:54Z

@erikh ok created a constant and used it on client and server

duglin · 2015-01-06T21:05:39Z

ok rebased and constant is made/used.

crosbymichael · 2015-01-06T22:19:01Z

@duglin Either we are working really fast today or you forgot to push your rebase ;)

Add a check to make sure Dockerfile is in the build context Add docs and a testcase Make -f relative to current dir, not build context Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin · 2015-01-07T00:34:51Z

no, I pushed it, but then #8748 caused a conflict.
rebased and added a testcase to make sure that the new .dockerignore processing (from #8748) works even when the Dockerfile is called something else.

crosbymichael · 2015-01-07T01:24:08Z

Nice

crosbymichael · 2015-01-07T01:25:16Z

Cool, i think this has enough LGTMs

Allow for Dockerfile to be named something else.

dreamcat4 · 2015-03-30T11:54:02Z

We also need this feature on the DockerHub (hub.docker.com) for it's Automated Builds. In the 'Edit Build Settings' page where it has the Field named 'Dockerfile Location'.

https://support.docker.com/hc/en-us/requests/3494

NOTE on Oct 13, 2015: This patch has now been obsoleted, since the merge of moby#9707 moby#9707 END NOTE Now one can perform the following commands in the same directory: docker build -t db_container -f db.dockerfile . docker build -t web_container -f web.dockerfile . docker build -t client_container -f client.dockerfile . docker build -t client_container . The last one will use the default Dockerfile file.

This was referenced Dec 17, 2014

Allow for Dockerfile to be named something else #7995

Closed

Proposal: docker build should allow arbitrary Dockerfile path #7284

Closed

duglin force-pushed the RenameDockerfile branch from 29ea78e to 0d7bf0e Compare December 17, 2014 13:56

crosbymichael added this to the 1.5.0 milestone Dec 17, 2014

crosbymichael reviewed Dec 17, 2014
View reviewed changes

duglin force-pushed the RenameDockerfile branch from 0d7bf0e to d3a86bf Compare December 17, 2014 21:27

duglin force-pushed the RenameDockerfile branch from d3a86bf to 2c7ffeb Compare December 18, 2014 03:23

duglin force-pushed the RenameDockerfile branch from c6c1dda to f057e20 Compare January 6, 2015 19:17

erikh reviewed Jan 6, 2015
View reviewed changes

erikh self-assigned this Jan 6, 2015

duglin force-pushed the RenameDockerfile branch from f057e20 to 7266dba Compare January 6, 2015 20:11

duglin force-pushed the RenameDockerfile branch from 7266dba to 179f202 Compare January 6, 2015 21:02

Allow for Dockerfile to be named something else.

eb3ea3b

Add a check to make sure Dockerfile is in the build context Add docs and a testcase Make -f relative to current dir, not build context Signed-off-by: Doug Davis <dug@us.ibm.com>

duglin force-pushed the RenameDockerfile branch from 179f202 to eb3ea3b Compare January 7, 2015 00:33

crosbymichael added a commit that referenced this pull request Jan 7, 2015

Merge pull request #9707 from duglin/RenameDockerfile

a67e738

Allow for Dockerfile to be named something else.

crosbymichael merged commit a67e738 into moby:master Jan 7, 2015

duglin mentioned this pull request Jan 7, 2015

Allow specifying of a dockerfile as a path, not piping in. #2112

Closed

ohord mentioned this pull request Jan 12, 2015

Add 'buildfile' option docker/compose#834

Closed

duglin deleted the RenameDockerfile branch January 22, 2015 22:31

SvenDowideit mentioned this pull request Jan 27, 2015

Post 1.4.1 docs update 2 #9739

Merged

thaJeztah mentioned this pull request Feb 1, 2015

capset() might randomly fail with -EPERM #4556

Closed

duglin unassigned erikh Feb 5, 2015

tristanz mentioned this pull request Apr 30, 2015

Add support for specifying .dockerignore file with -i/--ignore #12886

Closed

thaJeztah mentioned this pull request Oct 29, 2016

Proposal - Build multiple images from a single repository #9198

Closed

thaJeztah added area/builder kind/feature Functionality or other elements that the project doesn't currently have. Features are new and shiny labels Dec 2, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow for Dockerfile to be named something else. #9707

Allow for Dockerfile to be named something else. #9707

duglin commented Dec 17, 2014

crosbymichael commented Dec 17, 2014

crosbymichael Dec 17, 2014

cyphar commented Dec 17, 2014

tianon commented Dec 17, 2014

duglin commented Dec 17, 2014

duglin commented Dec 17, 2014

tianon commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

crosbymichael commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

LK4D4 commented Dec 17, 2014

cyphar commented Dec 17, 2014

LK4D4 commented Dec 17, 2014

duglin commented Dec 17, 2014

slafs commented Dec 17, 2014

duglin commented Dec 17, 2014

thaJeztah commented Dec 17, 2014

crosbymichael commented Dec 18, 2014

duglin commented Dec 18, 2014

LK4D4 commented Jan 6, 2015

duglin commented Jan 6, 2015

erikh Jan 6, 2015

erikh commented Jan 6, 2015

duglin commented Jan 6, 2015

duglin commented Jan 6, 2015

crosbymichael commented Jan 6, 2015

duglin commented Jan 7, 2015

crosbymichael commented Jan 7, 2015

crosbymichael commented Jan 7, 2015

dreamcat4 commented Mar 30, 2015

Allow for Dockerfile to be named something else. #9707

Allow for Dockerfile to be named something else. #9707

Conversation

duglin commented Dec 17, 2014

crosbymichael commented Dec 17, 2014

crosbymichael Dec 17, 2014

Choose a reason for hiding this comment

cyphar commented Dec 17, 2014

tianon commented Dec 17, 2014

duglin commented Dec 17, 2014

duglin commented Dec 17, 2014

tianon commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

crosbymichael commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

duglin commented Dec 17, 2014

cyphar commented Dec 17, 2014

LK4D4 commented Dec 17, 2014

cyphar commented Dec 17, 2014

LK4D4 commented Dec 17, 2014

duglin commented Dec 17, 2014

slafs commented Dec 17, 2014

duglin commented Dec 17, 2014

thaJeztah commented Dec 17, 2014

crosbymichael commented Dec 18, 2014

duglin commented Dec 18, 2014

LK4D4 commented Jan 6, 2015

duglin commented Jan 6, 2015

erikh Jan 6, 2015

Choose a reason for hiding this comment

erikh commented Jan 6, 2015

duglin commented Jan 6, 2015

duglin commented Jan 6, 2015

crosbymichael commented Jan 6, 2015

duglin commented Jan 7, 2015

crosbymichael commented Jan 7, 2015

crosbymichael commented Jan 7, 2015

dreamcat4 commented Mar 30, 2015