ToolingApiDistributionResolver.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Disable dependency verification when resolving tooling API clients from cross version tests.

    • -0
    • +1
    ./ToolingApiDistributionResolver.groovy
Disable dependency verification when resolving tooling API clients from cross version tests.

    • -0
    • +1
    ./ToolingApiDistributionResolver.groovy
Let ToolingApiAdditionalClasspathProvider take ToolingApiDistribution

and DependencyResolutionServices

so that implementors can provide additional classpath depending on

the under test tooling api version

Signed-off-by: Paul Merlin <paul@gradle.com>

    • -1
    • +1
    ./ToolingApiDistributionResolver.groovy
  1. … 4 more files in changeset.
Run performance test against fork point commit (#7337)

This closes https://github.com/gradle/gradle-private/issues/1526

Basically, the idea is, we should run feature branch performance tests against the distribution which is built from the "fork point commit". This can reduce the effects of performance regression which is not introduced by the feature branch.

Two tasks are added into the build and depended by performance task:

- `determineForkPoint`, run `git` command to determine the fork point commit. It's done during the execution phase, then it sets the commit for `buildForkPointDistribution` task.

- `buildForkPointDistribution`, try to build a distribution from the fork point commit.

`buildForkPointDistribution` is cachable so it only needs to run once. Its input is the fork point commit, the output is two files: a binary distribution and a tooling api jar. The generated binary distribution is used to run individual worker tests.

    • -3
    • +12
    ./ToolingApiDistributionResolver.groovy
  1. … 12 more files in changeset.
Use static ToolingApiDistributionResolver

Previously, to solve https://github.com/gradle/gradle-private/issues/1290,

we created https://github.com/gradle/gradle/pull/5502. However, this introduced

some concurrent issues: https://github.com/gradle/gradle-private/issues/1302

This PR makes ToolingApiDistributionResolver static to avoid concurrent issues

and /tmp filled up issues.

    • -10
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 1 more file in changeset.
Create and cleanup TAPI test directories in ${project}/build/tmp (#5502)

See https://github.com/gradle/gradle-private/issues/1290

Previously TAPI test temp directories were created in /tmp and they didn't get cleaned up

at all, which caused /tmp to be filled up quickly. This PR creates temp directories in the

same way as other tests - under ${project}/build/tmp/test files and cleans up them at last.

    • -3
    • +11
    ./ToolingApiDistributionResolver.groovy
  1. … 2 more files in changeset.
Introduce internal mirror for https://repo.gradle.org/gradle/repo

    • -1
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 5 more files in changeset.
Change the (internal) API used to create various kinds of builds to use a `BuildState` instead of `NestedBuildFactory` to represent the owning build. This way, `NestedBuildFactory` and `GradleLauncher` and friends become an internal concern of the build tree infrastructure.

    • -103
    • +5
    ./ToolingApiDistributionResolver.groovy
  1. … 23 more files in changeset.
Replace the `BuildIdentity` build scope service with the `BuildState` instance that represents the current build.

    • -7
    • +0
    ./ToolingApiDistributionResolver.groovy
  1. … 27 more files in changeset.
Change `ProjectComponentIdentifier` and `ProjectComponentSelector` implementations to carry enough information to report the correct display name and project name. Change more places to delegate to the `BuildState` for a particular build to determine these values for a given project, rather than duplicating the logic to calculate these things.

    • -2
    • +36
    ./ToolingApiDistributionResolver.groovy
  1. … 43 more files in changeset.
Make DefaultExecHandle respond to Ctrl-C (#5249)

This is an attempt to fix https://github.com/gradle/gradle/issue/2128

Previously, all execution actions (started by `DefaultExecHandle`) don't respond to Ctrl-C. This will cause unexpected daemon shutdown - when Ctrl-C is pressed, daemon wait 10s for everything to finish - but `DefaultExecHandle` don't respond, so the result is always daemon shutting down.

This PR creates `ExecFactory` as a build session scope service and injects `BuildCancellationToken` into `DefaultExecHandle` so that `DefaultExecHandle` can register hooks to the `BuildCancellationToken`.

    • -1
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 18 more files in changeset.
Inject services into `VcsDependencyResolver` on construction, rather than have it look these services up on resolve.

    • -0
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 3 more files in changeset.
Include GradleBuild task build operations in the build operation tree (#4560).

This is the conceptual intent. Furthermore, it's necessary for build operation notification based log output which will be required for scans.

    • -7
    • +9
    ./ToolingApiDistributionResolver.groovy
  1. … 26 more files in changeset.
Fixed tooling api int tests.

    • -0
    • +9
    ./ToolingApiDistributionResolver.groovy
Adjust tests to use the new experimental feature option

Signed-off-by: Jendrik Johannes <jendrik@gradle.com>

    • -2
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 23 more files in changeset.
Strive to keep Gradle's monotonic clock in sync with the system clock

    • -3
    • +4
    ./ToolingApiDistributionResolver.groovy
  1. … 71 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
    • +3
    ./ToolingApiDistributionResolver.groovy
  1. … 179 more files in changeset.
Remove unused code from test fixture

    • -24
    • +1
    ./ToolingApiDistributionResolver.groovy
Rename ExecutionScopeServices to BuildTreeScopeServices

The hierarchy is:

Global < BuildSession < BuildTree < Build < Gradle < Project

    • -7
    • +7
    ./ToolingApiDistributionResolver.groovy
  1. … 11 more files in changeset.
Wire Execution scope services into other scopes

    • -1
    • +4
    ./ToolingApiDistributionResolver.groovy
  1. … 10 more files in changeset.
Unify BuildOperationExecutor and BuildOperationProcessor APIs

This introduces the following `BuildOperationExecutor`

interface (as outlined in gradle/gradle#1676):

void run(RunnableBuildOperation buildOperation);

<T> T call(CallableBuildOperation<T> buildOperation);

<O extends RunnableBuildOperation> void runAll(

Action<BuildOperationQueue<O>> schedulingAction);

<O extends BuildOperation> void runAll(

BuildOperationWorker<O> worker,

Action<BuildOperationQueue<O>> schedulingAction);

To accomplish this, the following changes were performed:

- Various representation of build operations have been merged into

1) BuildOperation (with sub-interfaces)

-> declare and describe a build operation

2) BuildOperationDescriptor (BuildOperationDescriptor.Builder)

-> describe a build operation

3) BuildOperationState

-> represents a running build operation, with run state, start time,

parent relationship information, and description

- The DefaultBuildOperationExecutor and DefaultBuildOperationProcessor

implementations have been merged in DefaultBuildOperationExecutor,

which is now build session scoped.

    • -1
    • +1
    ./ToolingApiDistributionResolver.groovy
  1. … 180 more files in changeset.
Introduce convenience methods on worker lease service

    • -3
    • +4
    ./ToolingApiDistributionResolver.groovy
  1. … 22 more files in changeset.
ToolingApiDistributionResolver fixture now takes a worker lease

    • -0
    • +9
    ./ToolingApiDistributionResolver.groovy
BuildOperationProcessor emits build operation events

WIP

    • -1
    • +24
    ./ToolingApiDistributionResolver.groovy
  1. … 23 more files in changeset.
Changed the wiring of the listeners that forward events back to the tapi client so that they received events from _all_ builds, not just the root build. This in particular means that progress events are received from `buildSrc` builds, composite builds, and builds started using the `GradleBuild` task.

Cleaned up `BuildScopeServices` so that it is no longer responsible for cleaning up its parent.

    • -1
    • +5
    ./ToolingApiDistributionResolver.groovy
  1. … 7 more files in changeset.
Fixed test fixture broken due to shuffling around of services.

    • -3
    • +13
    ./ToolingApiDistributionResolver.groovy
Merge branch 'master' into composite-builds

    • -1
    • +2
    ./ToolingApiDistributionResolver.groovy
Remove deprecated methods on TestUtil (#672)

In order to use project builder correctly without having

leaking files on windows it is necessary to initialize

the test fixture for NativeServices and clean up

the test directory after building.

AbstractProjectBuilderSpec provides a nice base class

for Groovy tests.

I removed the deprecated methods since using them leads

to files lying around. Migrating all the usages to the "new"

way ensures it is used correctly.

    • -1
    • +2
    ./ToolingApiDistributionResolver.groovy
  1. … 97 more files in changeset.
Register composite build services for all builds

Instead of having a specific set of services only loaded for a composite

build, these services are registered for all builds, with an empty context

for any non-composite build.

    • -0
    • +3
    ./ToolingApiDistributionResolver.groovy
  1. … 7 more files in changeset.
Optimize ProjectScopeServices.createLoggingManager()

    • -2
    • +3
    ./ToolingApiDistributionResolver.groovy
  1. … 3 more files in changeset.