Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Fully document `MavenPom#project(Action)`

Instead of referring to the `Closure` based overload.

Update public Kotlin Slack link

Update public Kotlin Slack link

Fix RunningPlayApp since this is used when running Play outside of Gradle too

Revert "Revert "Look for the Play started message from Gradle vs Play""

This reverts commit e30c0ec54a32826550641ac9f095856c0ef2e5d2.

Revert "Look for the Play started message from Gradle vs Play"

This reverts commit 7318e374a7232b2c9bca7511eb8e280445217f37.

Look for the Play started message from Gradle vs Play

The Play framework seems to say its listening before the Play application fully starts

which causes a race condition in our integration tests.

Gradle produces a similar message after the Play application has had

time to start, so this should be after the application is ready.

:arrow_up: Kotlin 1.1.4-2

Fix behavior after rebasing from master

Reword info message as suggested in review of #2751

Accept small first use regression

The `FileHasher` is now always initialized early

instead of when the first task with inputs runs.

This is not a problem, because the scenario of

"starting the daemon, but never running a task

with inputs" is unrealistic.

Add integration test for configure project header of rich console

This test fails without the fix BuildOperationExecutor fix in d7ea3df.

Merge pull request #2716 from gradle/oehme/performance/zip

Make zipTree and tarTree faster

    • -2
    • +6
Respect --stacktrace for afterEvaluate error that is logged separately

Add running without --stacktrace option to test executers

Rebaseline all performance tests

  1. … 9 more files in changeset.
Fix failure handling in BuildOperationExecutor

The code block here had a very complicated flow with three nested

tries and finally blocks in between. This caused an issue where

the progress logger did not get the information if the operation

was failing. Because it ran in a finally {} block before the catch

block that recorded the failure.

This fixes this issue and also simplifies the code to only use two

try-blocks. The first is there to makes sure to do a proper

cleanup in case an exception is thrown. It does not execute user

coder directly (hence it only has a finally and no catch).

The inner block now only wraps the execution of the build operation

itself (which can contain user code). It catches and records

the failure before it is rethrown.

The corresponding unit test was actually wrong. It is fixed with

this commit.

Address PR feedback

- register listener after recorded events have been passed to listener

- tweak api of BuildOperationRecorder

Merge pull request #2749 from gradle/oehme/performance/stricter

Make performance tests stricter

Fix integration test: Set environment only for script that is executed

Preserve test-kit daemon logs on CI in case of test failure

There is a dedicated directory for test-kit daemon logs.

Added some validation to `PropertyState.set(Provider)` to fail when the given provider produces values that are not assignable to the property type.

Make test assertion more flexible: logging events use wall-clock time

See also 7923a9f

Fixed unit test for change to `Directory` and `RegularFile`.

Update `@since` tags

Mention contributor in release notes

See #2675

    • -1
    • +2
Remove unnecessary `final` qualifier

Use correct signature for Test::useJunit

Accepted some breaking changes.

Preserve compatibility with `kotlin-dsl`

    • -2
    • +2