Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Allow waiting on work submitted to a queue

  1. … 3 more files in changeset.
Allow waiting on work submitted to a queue

  1. … 3 more files in changeset.
Allow waiting on work submitted to a queue

  1. … 3 more files in changeset.
Apply `Anonymous type can be replaced with lambda` inspection the whole project

  1. … 666 more files in changeset.
Release project lock when instructed if all work items complete

With this change, a call to

`AsyncWorkTracker.waitForCompletion(RELEASE_PROJECT_LOCKS)` will _always_

release the project lock, even if all work items are complete. This means

the lock release is consistent whether or not the work items are

pending when the task action completes.

  1. … 1 more file in changeset.
Release project lock when instructed if all work items complete

With this change, a call to

`AsyncWorkTracker.waitForCompletion(RELEASE_PROJECT_LOCKS)` will _always_

release the project lock, even if all work items are complete. This means

the lock release is consistent whether or not the work items are

pending when the task action completes.

  1. … 1 more file in changeset.
Do not reacquire project lock when completing a worker-based task

The project lock is released if submitted work items are pending when the

task action completes. With this change, the lock is no longer reacquired

once these work items finish: instead, the task is marked as "complete"

without reacquiring the project-mutation lock.

This isn't quite correct, since there are cases where the project lock

should be reacquired, such as when a task as further task actions to execute.

This will be addressed in a subsequent commit.

  1. … 10 more files in changeset.
Do not reacquire project lock when completing a worker-based task

The project lock is released if submitted work items are pending when the

task action completes. With this change, the lock is no longer reacquired

once these work items finish: instead, the task is marked as "complete"

without reacquiring the project-mutation lock.

This isn't quite correct, since there are cases where the project lock

should be reacquired, such as when a task as further task actions to execute.

This will be addressed in a subsequent commit.

  1. … 10 more files in changeset.
Do not reacquire project lock when completing a worker-based task

The project lock is released if submitted work items are pending when the

task action completes. With this change, the lock is no longer reacquired

once these work items finish: instead, the task is marked as "complete"

without reacquiring the project-mutation lock.

This isn't quite correct, since there are cases where the project lock

should be reacquired, such as when a task as further task actions to execute.

This will be addressed in a subsequent commit.

  1. … 10 more files in changeset.
Do not reacquire project lock when completing a worker-based task

The project lock is released if submitted work items are pending when the

task action completes. With this change, the lock is no longer reacquired

once these work items finish: instead, the task is marked as "complete"

without reacquiring the project-mutation lock.

This isn't quite correct, since there are cases where the project lock

should be reacquired, such as when a task as further task actions to execute.

This will be addressed in a subsequent commit.

  1. … 10 more files in changeset.
Do not reacquire project lock when completing a worker-based task

The project lock is released if submitted work items are pending when the

task action completes. With this change, the lock is no longer reacquired

once these work items finish: instead, the task is marked as "complete"

without reacquiring the project-mutation lock.

This isn't quite correct, since there are cases where the project lock

should be reacquired, such as when a task as further task actions to execute.

This will be addressed in a subsequent commit.

  1. … 10 more files in changeset.
Organize imports

  1. … 339 more files in changeset.
Replace anonymous classes with lambdas

  1. … 711 more files in changeset.
Replace anonymous classes with lambdas

  1. … 695 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 890 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 897 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Remove synthetic accessors for internal private symbol references

  1. … 902 more files in changeset.
Include details of post-action wait time to build operation for task action

  1. … 3 more files in changeset.
Include details of post-action wait for task action

- Add type to build operation representing a single task action

- Record time spent waiting for work items after task action completes

  1. … 4 more files in changeset.
Include details of post-action wait for task action

- Add type to build operation representing a single task action

- Record time spent waiting for work items after task action completes

  1. … 3 more files in changeset.
Add a build operation for time task spends waiting

- Time spent waiting for worker items to complete

- Time spent waiting for project lock once work items are complete

    • -0
    • +37
    ./TaskWaitingBuildOperationType.java
  1. … 2 more files in changeset.
Speed up worker API cancellation

Previously we cancelled work items, but only after they

had already been started. This meant that cancellation could

take up to numberOfItems*timeToInterruptCheck time.

We now eagerly cancel the work items, so that they don't even

start executing. This limits the delay to the time it takes

a single item to interrupt.

  1. … 6 more files in changeset.
Simplify the check for incomplete work

  1. … 1 more file in changeset.
Fix issue with threads leaking from Worker API

  1. … 4 more files in changeset.
Polish

  1. … 2 more files in changeset.
Rationalise handling of “current” build operation and build operation ID

For an upcoming change to emit console logging as build operation progress events, we need to associate all progress logging with the build operation. This pulled a thread on some long overdue cleanup.

The end result is:

1. Base build operation infrastructure is consolidated org.gradle.internal.operations.

2. Mechanism for passing thread global current build operation is more test friendly, and better named.

3. A consistent mechanism is used for binding the current operation to the thread, instead of two mechanisms.

4. Build operation IDs are typed to OperationIdentifier.

There is no public API or user behaviour change.

  1. … 146 more files in changeset.
Replace Executor in WorkerLease convenience methods with Callable/Runnable

  1. … 9 more files in changeset.