'files' parameters is verified too early for a dynamically generated Docker context

[GJKrupa]

I'm trying to create a Docker context that only includes the output TAR from the distribution plugin so I've configured it as...

docker {
    dependsOn distTar
    name "${project.group}/${project.name}:${project.version}"
    tags "latest"
    buildArgs([BUILD_VERSION: project.version])
    files distTar.archivePath.absolutePath, 'Dockerfile'
}

This configuration is failing, however, because the Docker plugin is checking for the existence of this file during project configuration, long before it get created.

This isn't a huge issue but without specifying the 'files' parameter, the entire src/ directory plus build.gradle, gradle.properties etc. are also getting copied unnecessarily into the context.

[uschi2000]

Hej! Can you try removing the "files" parameter, please? See this test as an example: https://github.com/palantir/gradle-docker/pull/93/files#diff-42ea40a578e12c8725a6379907334c76R462

[GJKrupa]

Hi, as stated above (I added it in a later edit do you may not have seen it) the build works if I remove the 'files' parameter but copies a lot of unnecessary files into the context. In general, though, it would be a lot more powerful if it could be used specify derived as well as source files.

[uschi2000]

Ah, I didn't read your initial comment carefully enough, sorry. I agree that the current interaction of the dependsOn/files parameters is a bit unfortunate. The plugin functionality grew organically and the addition of the files parameter made things messy. I think we can revisit the behavior next time we break the API. Do you have a recommendation?

[GJKrupa]

Might be sufficient to use the 'archivePath' property of the dependsOn task if it exists to define the context and then fall back to the existing behaviour if it's not available. This property is exposed for, at the very least, the application, distribution, ear, war and jar plugins.

IMO the files parameter is useful should be able to handle 2 possible types of values:

• A mixed list of File and String (and GString) objects
• A closure that returns the above and is evaluated as late as possible

A couple of "nice to have" features would be a flag to indicate whether to flatten or maintain the directory structure and the ability to use Ant-style wildcards (but that then introduces the need for exclusion lists which gets even more messy).

[uschi2000]

Cool, thanks Gerard. Let's keep this ticket open as a reminder for your proposals. Realistically, nobody on our side will have time making any big changes here in the coming weeks, but we're always happy to accept contributions.

…

On Sun, Jan 15, 2017 at 9:57 AM Gerard Krupa ***@***.***> wrote: Might be sufficient to use the 'archivePath' property of the dependsOn task if it exists to define the context and then fall back to the existing behaviour if it's not available. This property is exposed for, at the very least, the *application*, *distribution*, *ear*, *war* and *jar* plugins. IMO the files parameter is useful should be able to handle 2 possible types of values: A mixed list of File and String (and GString) objects A closure that returns the above and is evaluated as late as possible A couple of "nice to have" features would be a flag to indicate whether to flatten or maintain the directory structure and the ability to use Ant-style wildcards. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#97 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGOdwfQbje5JdK9yFZ3SoHE9V6otZUZCks5rSe1fgaJpZM4Li9Ij> .