Allow different location for Dockerfile

[ysb33r]

Primary: The docker cmdline allows for -f to have the Dockerfile at a location other than the context directory. Similar functionality would be very very useful in the plugin as it allows for Dockerfile to be static and then the buildContextDirectory to reside in buildDir.

Secondary: The above functionality will then also allow for an auto-generated Dockerfile to be used. Some of the other plugins allows for the specificiation of a template that can be converted into a Dockerfile. Currently this can already be achieved in this plugin via a custom Copy task in a build script i.e.

task createDockerFile( type : Copy ) {
  from '/path/to/DockerFile.template'
  into "${buildDir}"

  rename { 'DockerFile' }

  expand {
    author : 'Joe Bloggs'
  }
}

Given the above example and if the DockerBuildTask supports a dockerFile property then one would even be able to do something like

dockerFile = createDockerFile.outputs.files.singleFile

P.S. One could actually create a new task type i.e. CreateDockerFileTask, but I'll raise another issue for that case.

[gesellix]

Please try version 2016-01-13T23-15-28. It allows you to configure the query parameters when the whole build context is uploaded to the Docker builder. See

gradle-docker-plugin/src/test/groovy/de/gesellix/gradle/docker/tasks/DockerBuildTaskSpec.groovy

Line 118 in 581badb

def "delegates to dockerClient with buildContext and buildParams"() {

for an example. Please note: [rm:true] is the default, so don't forget to add it when playing around with the [dockerfile:'...']. Another detail: the referenced Dockerfile needs to be contained in the build context, which effectively means that you have to configure a path relative to the build context root, but not starting with ../.

The current implementation is obviously the least convenient way, but it's a start ;-)

Could you describe the use case for the secondary goal? I personally prefer version controlled Dockerfiles instead of generated/templated ones. But let's discuss details in a dedicated issue.

[ysb33r]

Great, that's a good start. I think having the flexibility in there allows the script author to manipulate things at a lower level when the plugin does not offer support at DSL level. Obviously I would still like to see the support at high-level, but I can at least play around with it at this level.

As to the secondary case:

• I concur that having version-controlled Dockerfile is a good idea, and in many cases this is exactly what is needed.
• There are places where we would rather want to have a template version-controlled and then create the final Dockerfile from that template plus properties set in the build script.
• An example would be using a ADD where the location is determined by the build script.
• Another (possibly trivialised) example is that I want to build a container that's FROM base is java and I want to match the tag of that to the version of java using to run Gradle.

[ysb33r]

Please note: [rm:true] is the default

This was a great idea. It makes building containers a lot easier. (No need for an instance of a DockerRmiTask in most build scripts.)

[gesellix]

That was a great idea.

It's the official Docker client's default - it only has an effect on the intermediate containers which are created during the build of each layer, see the docs for all details.

[gesellix]

Lets keep this issue opened for a more convenient way of building images from a custom Dockerfile and add a new issue for the templated/generated Dockerfile. Would you like to add another issue, by describing some kind of desired example task? A bit late for Christmas presents, but you may tell me your wishes ;-)

[ysb33r]

Would you like to add another issue, by describing some kind of desired example task?

I'll take care of that.