Gradle

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix native performance tests

Support reconstructing exception in PayloadSerializer

+review REVIEW-6309

Make exception replacing serialization work with subclasses

+review REVIEW-6309

Don't assume exception is a RuntimeException

+review REVIEW-6309

Test non serializable exceptions in TAPI model builders

- GRADLE-3307

+review REVIEW-6309

Use exception replacement in PayloadSerializer

+review REVIEW-6309

Move ExceptionPlaceholder classes to top level

+review REVIEW-6309

Ignore timing when it's whole seconds in test report

Most of the time we get "0.001s", but sometimes we get "0s" or "1s".

+review REVIEW-6290

Restore cached file dates to millisecond precision

This is to support file systems like Ext4 and NTFS that have a granularity finer than 1 second.

+review REVIEW-6308

Propagate build output to aid in debugging failures

Remove redundant conditional

Remove redundant modifiers

Polish `MultiprojectProjectAndTaskListIntegrationTest`

- Use same project refresh timeout for all tests

- Fix braces formatting

- DRY

Mutate `dir` field only after creating unique test directory

Name `Sample.dir` after test method and class

By deferring the computation of dir until the first request.

Increase file cache lock timeout to 10 minutes

Gradle locks the cache for a period of time while modifying its contents (usually upon write access). In case the access exceeds the timeout, the build fails with an error message. Often times these situations occur under high load of the build machine. An end user doesn't really know how to interpret the build failure or how to correct it. We can safely increase this timeout to avoid common failure situations (e.g. with Zinc compiler). Any issue that will still pop up with the increased timeout likely indicates a bug in Gradle and will need to be addressed.

+review REVIEW-6306

    • -0
    • +9
    /subprojects/docs/src/docs/release/notes.md
Fix generation of "java software model" templates

    • -0
    • +4
    /subprojects/performance/templates.gradle
Actually cache Jacoco results

We haven't stored them previously. Now we have an integration test to make sure.

+review REVIEW-6301

Make sure test doesn't reuse previous output

+review REVIEW-6301

Extract abstract test class for local task output cache tests

+review REVIEW-6301

Use `buildSrc` instead of embedding classes in each subproject

The test projects all used their own copy of `CheckstyleExtension` and a custom plugin. This doesn't

reflect real projects at all. Instead, this commit changes the project layout to add a `buildSrc`

directory which contains those custom tasks/plugins.

    • -0
    • +4
    /subprojects/performance/templates.gradle
Make sure test doesn't reuse previous output

+review REVIEW-6290

Fix typo

+review REVIEW-6290

    • -1
    • +1
    /subprojects/docs/src/docs/release/notes.md
Simplify test code

+review REVIEW-6298

Apply all model mixins in build actions

Up until now many compatibilty mappings were only applied

when calling `ProjectConnection.getModel()`, but not when using

`BuildController.getModel()`. As a result, models retrieved by

a build action were less user friendly.

Both code paths now use the same compatibility mapping logic.

  1. … 16 more files in changeset.
Use less concurrent builds to avoid contention

In this test multiple builds try to execute the build. All of them need to create the Gradle API JAR as the test assumes a custom Gradle home directory. Creating a file lock on the same directory while running multiple builds concurrently might lead to a lock timeout issue (60 secs) depending on the load of the CI agent. Lowering the number of concurrent builds might elevate the issue.

+review REVIEW-6306

Prepare outputs even despite file type changes

Even if there is a file where we expect a directory, or vice versa, we need to be able to set the stage properly.

+review REVIEW-6298

Prepare output directories separately before unpacking cached result

+review REVIEW-6298

Ensure the daemon blocks for the duration of the test

LockSupport.park() may return immediately if a permit is available.

This cause the task to, sometime, keep executing without blocking. Code

examples show that LockSupport.park() should be use inside a loop

checking the "can proceed" condition. A different approach was choosen

to keep the code simple.

+review REVIEW-6307