Ease work with custom context

[agrrh]

Currently, there's an issue when you work with custom context:

settings:
  repo: repo/app
  context: app/

# $ docker build --rm=true -f Dockerfile -t ... app/

It translates to following command, which seeks for Dockerfile in root directory instead of context one (which is definitely more common situation) and gives us an error:

$ docker build --rm=true -f Dockerfile -t aa13f37ccf521ff651bbaa8fce5169a118aa6a89 app/
unable to prepare context: unable to evaluate symlinks in Dockerfile path: lstat /home/agrrh/repos/my-project/Dockerfile: no such file or directory

So we are forced to also state custom path also for dockerfile to make things happen:

settings:
  repo: repo/app
  context: app/
  dockerfile: app/Dockerfile

# works now!
# $ docker build --rm=true -f app/Dockerfile -t ... app/

Here I propose to not append dockerfile path to command when dockerfile is default one. It lets custom context to work as expected:

settings:
  repo: repo/app
  context: app/

# $ docker build --rm=true -t ... app/

Another way to solve the issue is to unconditionally prepend context path: -f {context}/{dockerfile}.

What do you think?

[bradrydzewski]

does this have any potential to break existing projects? I recognize that this pull request brings the plugin more in line with the default docker behavior (which is great!) but we also need to be mindful of existing projects given this plugin has widespread use.

[agrrh]

@bradrydzewski What we break is a single case when someone is relying on this non-obviousness and using common /Dockerfile to build multiple images in /foo, /bar, /baz, etc. Seems a rare situation to me.

This change makes Drone logic closer to Docker one, as you correctly mentioned, thus making usage more intuitive.

[tboerger]

I don't know how many people are affected by this breaking change, but being more in line with Docker seems good to me.