-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
'files' parameters is verified too early for a dynamically generated Docker context #97
Comments
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 |
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. |
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? |
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 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). |
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>
.
|
I'm trying to create a Docker context that only includes the output TAR from the distribution plugin so I've configured it as...
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.
The text was updated successfully, but these errors were encountered: