Allow build operation listeners to log (#4693)This change moves build operation listening out of the standard listener infrastructure, to remove serialisation guarantees. As logging output now causes build operation notifications, whenever a build operation listener logged something it would fail due to the listener manager blocking overlapping signals.By moving build operation listening out, overlapping and concurrent signals are now allowed.This places more responsibility on listener implementations (e.g. thread safety), but there are few and they are all internal.Additionally, listeners will now never receive progress notifications before start notifications and after finish notifications for that operation.
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.
Rationalise handling of “current” build operation and build operation IDFor 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.
Emit the origin build invocation ID and execution time of tasks reusing outputs (#3846)Previously, we emitted the build invocation ID for both up-to-date and from-cache,but emitted the original execution time only for from-cache. This is now unified.Moreover, these values now reflect the true origin when from-cache outputs are reused as part of incremental build. Previously, the values from the first build to consider the task up-to-date after a from cache was considered as the origin for subsequent executions. Now, the origin information is kept from the from-cache execution.