ApplyPluginIntegSpec.groovy

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Fix tests

  1. … 3 more files in changeset.
Update Spock framework to 1.3

  1. … 24 more files in changeset.
Update Spock framework to 1.3

  1. … 24 more files in changeset.
Let integration tests in 'core' not use deprecated configurations

  1. … 11 more files in changeset.
Let integration tests in 'core' not use deprecated configurations

  1. … 11 more files in changeset.
Let integration tests in 'core' not use deprecated configurations

  1. … 11 more files in changeset.
Let integration tests in 'core' not use deprecated configurations

  1. … 11 more files in changeset.
  1. … 24 more files in changeset.
  1. … 24 more files in changeset.
  1. … 24 more files in changeset.
  1. … 24 more files in changeset.
  1. … 24 more files in changeset.
Let test relying on the Gradle API jar location `requireOwnGradleUserHomeDir()`

On CI redirect maven central queries to local repo for integration tests

  1. … 108 more files in changeset.
Run tests that are now relevant (#1875)

* Run tests that are now relevant

* Fix formatting and imports

* Undo unintentional formattings

* Undo unintentional formattings

* Clarify test

  1. … 9 more files in changeset.
Temporarily mark some failing specs as @MustFixForV4

  1. … 15 more files in changeset.
Upgrade Spock to version 1.1-groovy-2.4-rc-3

  1. … 16 more files in changeset.
Wire integration test build context instance

- enables using performance test specific build context when an instance

is properly wired

  1. … 48 more files in changeset.
Add test case for ProjectBuilder to verify proper behavior

  1. … 1 more file in changeset.
Switch test back on

Ignore `ApplyPluginIntegSpec` for daemon integration tests on Windows

While this test now appears to be relatively stable on Linux (reduced or

eliminated flakiness), it now fails consistently on Windows. This failure

should be investigated and fixed, so that this test can be re-enabled.

Reuse the integration test gradleUserHome for nested ProjectBuilder

Without this setting, the unit test that is created in the build executed

by the integration test uses an empty GradleUserHome, forcing it to

regenerated the gradle-api jar. This change allows the user home for the

integration test to be shared with the unit test `ProjectBuilder`.

  1. … 2 more files in changeset.
Don't need a separate gradle user home for test

Try test again on Windows CI

Temporarily disable test on Windows, to avoid persistent failure

Renamed `GradleExecuter.requireGradleHome` -> `requireGradleDistribution`

  1. … 29 more files in changeset.
Attempt to fix `ApplyPluginIntegSpec` by propagating native dir to compile and test processes

Reuse `nativeServices` installation in tests created within `ApplyPluginIntegrationSpec`

The test process, launched by the gradle process, launched by the integration

test will now use the native services directory provided by the integration

test, rather than re-initializing the native services in a temporary test dir.

  1. … 1 more file in changeset.
Attempt to fix flaky `ApplyPluginIntegSpec`

This test declares and executes a gradle build,

that compiles and runs a unit test,

that in turn uses `ProjectBuilder` to mock a Gradle project,

that applies the 'groovy' plugin.

Turtles all the way down.

This fix ensures that the inner test specifies the Gradle project directory

for the inner-inner Gradle project to use, so that this directory can be

cleaned up correctly by the owning integration test. (Without configuration,

the `ProjectBuilder` will use a directory under 'tmp' using `deleteOnExit`)

The `ProjectBuilder` may initialize `NativeServices` in it's project directory.

I suspect this might be causing the DaemonExecuter to die, because unless

NativeServices has already been initialized in the Daemon process, it will

be initialized in the to-be-deleted directory under `tmp`.

Use own Gradle user home dir for test