Zip task still 'up-to-date' after 'into' directory changes

The following task is always up to date when changing the ‘into’ directory. Is this the expected behavior or a bug? If its the former, then what is the correct workaround?

apply plugin:'java'
  task dist(type:Zip) {
   into 'dir1/'
   from jar

What do you mean by “when changing the ‘into’ directory”? This refers to a directory inside the generated zip.

I mean modify ‘dir1/’ to ‘dir2/’ and the run the build. Gradle does not see this change and the zip output is not updated.

I see. I believe it’s a known limitation that is yet to be addressed. I’m not aware of a generic workaround other than running ‘clean dist’ or ‘cleanDist dist’, or enforcing regeneration with ‘dist.outputs.upToDateWhen { false }’. Note that the dist zip will be regenerated automatically whenever the Jar changes, but changes to the target structure aren’t currently detected.

This is a serious issue since this means one can not trust the output of our CI server unless you run a clean before every build. Not having to do this is one of the major features of Gradle.

  1. Can you create/provide a tracker issue for this bug? 2. Is this limitation documented in the DSL or user guide? 3. Does this bug extend to other tasks such as Copy or others?

Please see for related issue(s). This is a limitation of all tasks that use copy specs, and to my knowledge it is only documented in JIRA. I’m aware of at least one other case where a build script change that may change the output of a task currently goes undetected, namely when changing the implementation of an ad-hoc task action. Having completely fool-proof up-to-date checks is a definite goal, but at this time, I recommend to run a clean build whenever absolute correctness is paramount and no room for error exists (release builds, possibly other CI builds).

Can’t this be solved by making all copy tasks have an input dependency on the gradle file?

Only to some extent, and it would be too coarse-grained. A better solution is needed.