Clone Tools
  • last updated a few seconds ago
Constraints: committers
Constraints: files
Constraints: dates
Change the console build status rendering to use the progress operation events associated with various build operations rather than injecting some additional synthetic progress events into the event stream to communicate this information. This avoids the cost of handling these additional events.

As a side benefit, the configuration phase % complete calculation now takes included builds into account.

  1. … 25 more files in changeset.
Merge stdout/stderr chains and introduce a throttled plain console

  1. … 7 more files 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.

  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.

  1. … 147 more files in changeset.
Simplify time handling internally and for build scans (#2857)

* Don't make TimeProvider Serializable.

This isn't safe and generally doesn't make sense.

* Extract and promote the concept of a build timer.

This was previously not well defined and being overlaid with the concept of when a user/tool requested something, which is not always the same thing.

* Pare down the deprecated org.gradle.util.Clock down to the minimum required.

Internal usage is replaced by a `getStartTime()` directly on BuildRequestContext.

What is left is only kept for backwards compatibility with scans.

* Rename TimeProvider to Clock.

* Move BuildExecutionTimer out of baseServices into core, and into a better package.

* Remove unused.

* Simplify the time package by merging types.

* Prevent the client's build started timestamp from being later than when the provider received the build request.

* Provide a dedicated mechanism for conveying the build start time to build scans.

* Consolidate the ways of formatting durations.

  1. … 179 more files in changeset.
Removed `TimeProvider.getCurrentTimeForDuration()`

The `ReliableTimeProvider` now produces a ms timestamp that is usable

for durations, and `Timers.startTimer()` is best for calculating

relative times.

  1. … 12 more files in changeset.
Fix test

Send total progress for progress logging with the progress start event

  1. … 17 more files in changeset.
Add explicit knowledge about failure to ProgressCompleteEvent

  1. … 18 more files in changeset.
Change styled label to use predefined styles

Use events.StyledTextOutputEvent.Span instead of text.Span

  1. … 8 more files in changeset.
Color the progress bar in the console

For this, the ProgressEvent is enriched with the actual progress

information as int values and the progress bar rendering is moved

to the client.

  1. … 20 more files in changeset.
Use verb phrase and avoid all caps in progress log description for build phases

  1. … 1 more file in changeset.
Hide and restart build timer between continuous builds

Detect when a build started in build status renderer by checking

for the root operation id (extracted constant to OperationIdentifier)

Track when we're between root build phases and hide the timer by

adjusting the build status formatter depending on whether the timer

should be enabled.

Issue: #2068

  1. … 5 more files in changeset.
Add functional test coverage for build status display

  1. … 2 more files in changeset.
Rename progress.BuildOperationType to BuildOperationCategory

  1. … 16 more files in changeset.
Remove unnecessary fields from progress events

This change removes the category from progress and progress

complete events. They are never used in logging because the

category from the start event is used for generated log messages.

Similarly, the timestamp is removed from progress events as it's

never used.

Finally, the description for progress complete events is never


All of these reduce the serialization burden of a now much-larger

number of progress events, resulting in improved performance.

  1. … 11 more files in changeset.
Dynamic work-in-progress in Parallel Console (#1965)

Increase WIP size as more parallel work is added, now ignoring `--max-workers`.

Track renderability of progress operations and do not render operations that complete immediately or aren't renderable.

Issue: #1833

  1. … 6 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

  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

  1. … 46 more files in changeset.
Revert some logging changes

- Move OperationIdentifier back to logging and use Objects for

BuildOperation ids

- Remove log event builders and use plain constructors to avoid too

much garbage

  1. … 54 more files in changeset.
Mark log events with their associated build operation id

Use BuildOperationIdentifierRegistry in all of the places where

we generate renderable output events to set build operation id.

Serialize Operation identifiers coming from forked processes.

Use Builder pattern for constructing renderable output events to

avoid an explosion of constructors while maintaining forward

compatibility. (0 uses of StyledTextOutputEvent in non-forked

repos, so removed those constructors, they're internal anyway)

Reuse BuildOperation ids through progress logging where we


Issue: #1611

  1. … 55 more files in changeset.
Build elapsed time summary (#1689)

* Indicate Gradle's continued progress in the format `3h 23m 2s`

* Improve AntLoggingAdapterTest to avoid flaky test

  1. … 10 more files in changeset.
Fix flaky test in ConsoleFunctionalTest

Revert `BatchOutputEventListener` in preference to more localized change

  1. … 16 more files in changeset.
Draft parallel console implementation

This allows Gradle to show multiple items in progress when attached

to an interactive terminal.

This is achieved by:

First, breaking apart ConsoleBackedProgressRenderer into 3 filters:

- ThrottlingOutputEventListener buffers OutputEvents and flushes

them after a certain period of time or if the build has ended

- BuildStatusRenderer maintains a Label that displays overall

build progress (formerly the "status bar")

- WorkInProgressRenderer maintains a BuildProgressArea and

associates one branch of a ProgressOperations "tree" to a Label

representing work in progress for multiple workers.

Second, externalizing and enhancing concepts within AnsiConsole:

- Cursor represents a position in the terminal, using a cartesian

coordinate system with origin (0, 0) at the bottom left

- MultiLineProgressArea is a TextArea implementation with

addressible lines through Labels.

- Style represents ANSI text colors and emphases.

- Span is simply an association between a Style and String of


- AnsiExecutor is an ANSI-aware text writer. It accepts Actions

that may reposition the Cursor and write styled text

Finally, logging improvements. Project evaluation logging was

extracted from build progress logging. Build progress logs are

formatted with a ProgressBar formatter and submitted through

the same ProgressOperations mechanism. These ProgressOperations

are selected by the BuildStatusRenderer and rendered separately

from other ProgressOperations for now. In the future, we will

have must stronger semantics around this using BuildOperations.

Issue: gradle/gradle-private#649

    • -0
    • +275
  1. … 67 more files in changeset.