Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Cleanup stale output files during execution (#2572)

We now keep a registry of all the outputs generated by Gradle which will be reset on each version change. If Gradle encounters an existing output file, then it will remove it if is not part of the registered outputs and owned by Gradle/the build. We do also not remove directories containing outputs from different tasks.

The check to delete the stale outputs happens now just before the task executes and not up-front as it did before.

The `build` directory and all delete targets of the `clean` task are registered as owned by Gradle and are considered safe to delete.

Currently, the set of recorded task output files is only growing if we do not change the Gradle version. In the future we can improve on this by also detecting that some directories where removed (e.g. by running a clean task) and reflect this in the registry.

Fixes #1168

Fixes #973

+review REVIEW-6557

  1. … 18 more files in changeset.
TeamCity change in 'Gradle :: Promotion' project: runners of 'Master - Nightly Snapshot' build configuration were updated

TeamCity change in 'Gradle :: Promotion' project: runners of 'Master - Nightly Snapshot' build configuration were updated

Merge branch 'release'

Merge branch pm/flaky-fix-it/tapi-tests'

Don't apply the incremental source file analysis to Swift source files, as they don't have header files and all source files need to be compiled together. Incremental compilation will be implemented later.

This change fixes an issue where compilation would fail when some, but not all, source files of a project has changed since last compilation.

Add Thomas Halm to release notes

    • -0
    • +1
Some tweaks to test case names.

Ensure `XcodeProject` and `XcodeWorkspace` properties of `XcodeExtension` are proper DSL elements, use `ObjectFactory` to do this.

Added some unit test coverage for `DependencyInjectingInstantiator`

Introduce `withGroovyBuilder` interoperability utility

For interoperability with plugins that rely on Groovy builders such as

the core `maven` plugin.

See #47

Add `maven` plugin configuration sample

Resolves #142

    • -0
    • +13
    • -0
    • +45
    • binary
    • -0
    • +169
    • -0
    • +84
    • -0
    • +0
Add test with a failing build and pending changes

Adjust tests to new cross-version test handling

Add must-run-after rules to ensure that test projects are created first

Fix subproject definitions

    • -5
    • +5
Merge pull request #445 from jaredsburrows/jb/remove-applyfrom

Remove "applyFrom" to achieve symmetry with "apply { plugin(...) }"

Add issue and PR templates

Add issue and PR templates

remove applyfrom to achieve symmetry with apply plugin

Add `Action<T>` overloads to `maven` plugin API


- Add `Action<T>` overloads to `PomFilterContainer`

- Add `Action<T>` overloads to `MavenRepositoryHandlerConvention`

- Accept `maven` plugin API changes

See gradle/kotlin-dsl#142

Move action class back to test folder

The class was accidentally moved into the "testFixtures" folder. These

classes are not on the classpath of the Gradle that runs the build.

Polish TAR archiving of task outputs

Remove dependency on run-support

We weren't really using it anyways

Add XCode support for Swift project (#2579)

Reusing the IDE generator task infrastructure from Idea and Eclipse. The code for generating Xcode files comes from the Bazel tool which in turn comes from Buck tool. Xcode support for Swift code works with executables, libraries, and multi-projects.

    • -0
    • +3
  1. … 52 more files in changeset.
Enable build cache for performance tests

The build cache is now enabled for the performance test coordinator and

individual performance test workers.

Temporarily ignore Kotlin DSL tests

Because of PluginRequestApplicator API breakage in previous commit

Add {non,}Abi change tests with build cache

+review REVIEW-6556

Consolidate build cache performance tests

There is now only one class which contains all the tests. We now always

have the local cache enabled (push = true), since this is the default

use case. For the remote cache tests we clean the local cache after each


We also added a new test which tests pushing to the remote build cache.

+review REVIEW-6556