There is a per-task work-around, as the Ants default excludes (not only like them, but literally) are used, you can manipulate them like the following:

import org.apache.tools.ant.DirectoryScanner
task makeZip(type: Zip) {
   doFirst {
      DirectoryScanner.defaultExcludes.each { DirectoryScanner.removeDefaultExclude it }
      DirectoryScanner.addDefaultExclude 'something has to be in here or everything gets excluded'
   }

   baseName 'test'
   from 'test'

   doLast {
      DirectoryScanner.resetDefaultExcludes()
   }
}

It could be improved by storing the defaults before and restoring them afterwards and similar stuff of course. This is just for proof of concept. This worked with a .gitignore in the test directory.

It could of course cause problems like if the defaults were modified before and they get reset to default (one could save the state and restore it exactly) or if the copy fails and --continue is used, the defaults are changed for other tasks that follow (maybe using event listeners to reset the defaults could be used to fix this), or if you use --parallel you could influence other tasks (I guess here nothing can be improved than not to use --parallel).

Of course the ant task DefaultExcludes could also be used to manipluate the default excludes list, as could the ant.zip task be used which supports the defaultExcludes: 'no' property

This behaviour violates the principle of least surprise, and compounds the surprise by failing to even notify that files are going to be skipped. I realize it's basically impossible to push out a new release that disables this behaviour, but the fact that it's not even mentioned in the docs for the copy spec is kind of brutal, for those of us who stumble into it!

As announced on the Gradle blog we are planning to completely migrate issues from JIRA to GitHub.

We intend to prioritize issues that are actionable and impactful while working more closely with the community. Many of our JIRA issues are inactionable or irrelevant. We would like to request your help to ensure we can appropriately prioritize JIRA issues you’ve contributed to.

Please confirm that you still advocate for your JIRA issue before December 10th, 2016 by:

• Checking that your issues contain requisite context, impact, behaviors, and examples as described in our published guidelines.
• Leave a comment on the JIRA issue or open a new GitHub issue confirming that the above is complete.

We look forward to collaborating with you more closely on GitHub. Thank you for your contribution to Gradle!

Unless otherwise advised, I think this is still an issue in recent Gradle.

The work is now tracked here: https://github.com/gradle/gradle/issues/1348