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.
06 Mar 18 bb104be7d25edd589a47185026663c744a2e2ae0
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.
04 Sep 17 2f94bfed05d248447439febefb45e841b7d73793