Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Use some knowledge of the output event stream to reduce the number of strings that are written to the daemon client during serialization.

    • -1
    • +41
  1. … 3 more files in changeset.
Remove the 'parent build operation' property from `ProgressStartEvent` as this can be inferred from the other properties. Reduce the amount of mapping required to perform console output grouping and to simplify the output event stream before it is seen by any consumers.

    • -13
    • +9
  1. … 11 more files in changeset.
Merge the 'short description' and 'status' properties on progress start events, to avoid the cost of tracking and serializing these separately.

    • -83
    • +5
  1. … 22 more files in changeset.
Change the allocation of progress operation ids so that it is likely that the progress operation id and build operation id of a given start event are the same, and take advantage of this to avoid serializing the build operation id and parent build operation id when they are same as the corresponding progress operation id.

A later change could potentially merge these two separate ids and avoid the cost of tracking two separate, but almost always correlated, values.

    • -0
    • +23
  1. … 11 more files in changeset.
Optimize the serialization for `ProgressStartEvent` instances sent from daemon to client for two very common usage patterns where either the description and short description or the short description and logging header are duplicates.

Neither of these patterns really make sense, and so shouldn't really need optimizing for, but this change does not attempt to address that issue.

    • -5
    • +84
  1. … 1 more file in changeset.
Emit build operation progress events for logging output (#4537)

* Tweak BuildOperationListener#progress api

* Use build operation id to reference progress

* Add workaround for tracing log output via build operation progress for composite builds

* Replace some Object typing of operation identifiers with OperationIdentifier.

* Associate all progress logging with the current build operation.

* Update logic to accommodate for all progress events now having build operation IDs.

* Don't allow ProgressStartEvent.buildOperationCategory to be null.

** Default it to uncategorized.

    • -3
    • +6
  1. … 50 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.

    • -2
    • +2
  1. … 147 more files in changeset.
Send total progress for progress logging with the progress start event

    • -3
    • +5
  1. … 17 more files in changeset.
Make progress event serialization more compact

Use a single byte to indicate nullness of all optional fields

instead of writing one byte for each of them.

    • -8
    • +7
  1. … 2 more files in changeset.
Rename progress.BuildOperationType to BuildOperationCategory

    • -8
    • +8
  1. … 16 more files in changeset.
Group logs by project and task

Introduces a BuildOperationType enum and adds it to the

default BuildOperationDescriptor. Passes this information

to the logging infrastructure through the BuildOperationExecutor.

All BuildOperations now have a ProgressLogger. This allows

progress logging to maintain a heirarchy of build operations,

otherwise we would not be able to group many log events.

ProgressStartEvents are given additional information in a

compact form to allow a tree of build operations to be

maintained and their operation types associated. This allows us

to associate log events who aren't fired by progress logging to

still be grouped.

A LogGroupingOutputEventListener uses these build operation

types and the build operation heirarchy to buffer and output

logs related to tasks and project configurations.

Issue: #1818

    • -0
    • +95
  1. … 30 more files in changeset.
Add build operation types to log events

This will allow OutputEventListeners to react to output events

from different types of operations differently.

Remove BuildProgressLogger and move progress bar logic and

rendering to BuildStatusRenderer where it belongs.

Issue: #1818

    • -0
    • +84
  1. … 46 more files in changeset.