serializer

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Handle logging of null value correctly

This fixes a bug where calling logger with any level with null as argument would result in stopping the daemon. Fixed by calling readNullableString.

Fixes #6661

Signed-off-by: Cliffred van Velzen <cliffred@cliffred.nl>

  1. … 1 more file in changeset.
Change the user prompt infrastructure to give the user some feedback when they enter a value that isn't valid for the question. Add some test coverage for user prompting.

    • -0
    • +35
    ./PromptOutputEventSerializer.java
    • -3
    • +1
    ./UserInputRequestEventSerializer.java
  1. … 22 more files in changeset.
Use some knowledge of the output event stream to reduce the number of strings that are written to the daemon client during serialization.

    • -17
    • +66
    ./ProgressStartEventSerializer.java
  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.

    • -21
    • +1
    ./ProgressStartEventSerializer.java
  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.

    • -42
    • +11
    ./ProgressStartEventSerializer.java
  1. … 22 more files in changeset.
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.

    • -17
    • +4
    ./ProgressStartEventSerializer.java
  1. … 25 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.

    • -8
    • +22
    ./ProgressStartEventSerializer.java
  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.

    • -24
    • +52
    ./ProgressStartEventSerializer.java
  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.

    • -8
    • +27
    ./ProgressStartEventSerializer.java
    • -2
    • +2
    ./StyledTextOutputEventSerializer.java
  1. … 48 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
    • +1
    ./ProgressCompleteEventSerializer.java
    • -1
    • +1
    ./StyledTextOutputEventSerializer.java
  1. … 143 more files in changeset.
Capture user input via internal API (#3007)

    • -0
    • +36
    ./UserInputRequestEventSerializer.java
    • -0
    • +36
    ./UserInputResumeEventSerializer.java
  1. … 27 more files in changeset.
Properly serialize LogGroupHeaderEvents

    • -0
    • +68
    ./LogGroupHeaderEventSerializer.java
  1. … 4 more files in changeset.
Send total progress for progress logging with the progress start event

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

    • -1
    • +3
    ./ProgressCompleteEventSerializer.java
  1. … 18 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.
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.

    • -31
    • +92
    ./ProgressStartEventSerializer.java
  1. … 2 more files in changeset.
Rename progress.BuildOperationType to BuildOperationCategory

  1. … 16 more files in changeset.
Optimize serialization of empty logging operation ids

This reserves 0 as a special operation id value and changes all

construction of OperationIdentifiers to avoid a 0 value. This

allows for compact serialization of progress and build operation

ids because we can serialize a 0 value and deserialize as empty.

    • -9
    • +16
    ./ProgressStartEventSerializer.java
  1. … 4 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

used.

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

number of progress events, resulting in improved performance.

    • -5
    • +1
    ./ProgressCompleteEventSerializer.java
  1. … 10 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
    • +17
    ./ProgressStartEventSerializer.java
  1. … 30 more files in changeset.
Rename progress event operation id fields to make their purpose clearer

    • -1
    • +1
    ./ProgressCompleteEventSerializer.java
  1. … 5 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
    • +71
    ./PhaseProgressStartEventSerializer.java
    • -1
    • +1
    ./ProgressCompleteEventSerializer.java
  1. … 43 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
    • +1
    ./ProgressCompleteEventSerializer.java
    • -11
    • +10
    ./StyledTextOutputEventSerializer.java
  1. … 50 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

can.

Issue: #1611

    • -1
    • +1
    ./ProgressCompleteEventSerializer.java
    • -7
    • +14
    ./ProgressStartEventSerializer.java
    • -2
    • +11
    ./StyledTextOutputEventSerializer.java
  1. … 51 more files in changeset.
WIP on moving logging events to custom serializer

    • -0
    • +52
    ./LogEventSerializer.java
    • -0
    • +42
    ./LogLevelChangeEventSerializer.java
    • -0
    • +44
    ./ProgressCompleteEventSerializer.java
    • -0
    • +42
    ./ProgressEventSerializer.java
    • -0
    • +55
    ./ProgressStartEventSerializer.java
    • -0
    • +42
    ./SpanSerializer.java
    • -0
    • +53
    ./StyledTextOutputEventSerializer.java
  1. … 8 more files in changeset.