integration-testing

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Remove unused import

Add OS as inputs for unit tests (#11310)

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

Previously we only add OS as inputs for integration tests but not for unit tests. This results in missing test coverage for some unit tests.

We need to add OS as inputs of unit test task as well.

  1. … 1 more file in changeset.
Rework the discovery and validation of the JVMs used for building, compiling and testing Gradle, so that the implementation is compatible with instant execution.

In particular, model the `AvailableJavaInstallations` as a 'build service', in part to dogfood this API. Also remove some logic that is no longer required.

  1. … 6 more files in changeset.
Merge pull request #11211 from gradle/eskatos/ie/instantIntegTest-prepare-for-ci

Prepare CI pipeline to run integ tests with instant execution enabled

  1. … 4 more files in changeset.
Depend on all types of Gradle distributions for distributions integTests

Merge pull request #11204 from gradle/eskatos/smoke-test/generated-api-jars

Let smoke tests segregate the partial distro generated api jars

  1. … 2 more files in changeset.
Dedupe `rootProject.layout` policy for `intTestHomeDir/generatedApiJars`

  1. … 1 more file in changeset.
Disable :instantIntegTest tasks for now

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

Let smoke test reuse the partial distro generated api jars

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

  1. … 2 more files in changeset.
Introduce 'instant' Gradle executer for tests, aka. :instantIntegTest

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

  1. … 2 more files in changeset.
Remove samples from -all distribution

  1. … 6 more files in changeset.
Split cross version tests at quick feedback stage

Previously we accidentally skipped splitting crossVersionTest at

quick feedback stage, which caused them to be run multiple times.

This comomit fixes this issue.

Split cross version tests at quick feedback stage

Previously we accidentally skipped splitting crossVersionTest at

quick feedback stage, which caused them to be run multiple times.

This comomit fixes this issue.

Split cross version tests at quick feedback stage

Previously we accidentally skipped splitting crossVersionTest at

quick feedback stage, which caused them to be run multiple times.

This comomit fixes this issue.

Don't split integMultiVersionTest

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

Don't split integMultiVersionTest

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

Don't split integMultiVersionTest

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

Split cross version tests by task (#10896)

We didn't split cross version tests before, because some of them have own test class split. However, we see large cross version test timeout frequently.

This PR splits cross version tests by task, not by test class. For example, for version [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7]:

- -PtestSplit=1/3: [1.0, 1.3, 1.6]

- -PtestSplit=2/3: [1.1, 1.4, 1.7]

- -PtestSplit=3/3: [1.2, 1.5]

  1. … 2 more files in changeset.
Split cross version tests by task (#10896)

We didn't split cross version tests before, because some of them have own test class split. However, we see large cross version test timeout frequently.

This PR splits cross version tests by task, not by test class. For example, for version [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7]:

- -PtestSplit=1/3: [1.0, 1.3, 1.6]

- -PtestSplit=2/3: [1.1, 1.4, 1.7]

- -PtestSplit=3/3: [1.2, 1.5]

  1. … 2 more files in changeset.
Split cross version tests by task (#10896)

We didn't split cross version tests before, because some of them have own test class split. However, we see large cross version test timeout frequently.

This PR splits cross version tests by task, not by test class. For example, for version [1.0, 1.1, 1.2, 1.3, 1.4, 1.5, 1.6, 1.7]:

- -PtestSplit=1/3: [1.0, 1.3, 1.6]

- -PtestSplit=2/3: [1.1, 1.4, 1.7]

- -PtestSplit=3/3: [1.2, 1.5]

  1. … 2 more files in changeset.
Fix incorrect split (#10689)

I made a mistake when splitting the test sets: suppose we have 1000 tests and want to split into 3 buckets, the previous split is [333,333,333,1], so the test include/exclude patterns are:

- include 1..333

- include 334..666

- exclude 1..999

We're missing a large subset of tests! This fixes this issue by correctly splitting the buckets.

  1. … 2 more files in changeset.
Make buckets in TeamCity configuration (#10552)

Currently, the primary obstacles for us to improve CI feedback time is the long-running jobs: `integTest`/`core`/`dependencyManagement` each takes more than 10 minutes. Without decreasing the time we can't improve CI feedback time.

This PR changes the previous subproject-based TC job to bucket-based TC job: a bucket can contain a split of large subproject, or many tiny subprojects. This makes CI configuration more flexiable and efficient.

For example, all tiny subprojects which only contain unit tests can be merged to `AllUnitTests`, just as before - but now we make this more generic.

`integTest` subproject can be split to 3 jobs: `integTest`/`integTest_2`/`integTest_3`. Splitted project has a special parameter `-PtestSplit=1/3`/`-PtestSplit=2/3`/`-PtestSplit=3/3` so the build can choose only a subset of tests to execute.

  1. … 8 more files in changeset.
Make buckets in TeamCity configuration (#10552)

Currently, the primary obstacles for us to improve CI feedback time is the long-running jobs: `integTest`/`core`/`dependencyManagement` each takes more than 10 minutes. Without decreasing the time we can't improve CI feedback time.

This PR changes the previous subproject-based TC job to bucket-based TC job: a bucket can contain a split of large subproject, or many tiny subprojects. This makes CI configuration more flexiable and efficient.

For example, all tiny subprojects which only contain unit tests can be merged to `AllUnitTests`, just as before - but now we make this more generic.

`integTest` subproject can be split to 3 jobs: `integTest`/`integTest_2`/`integTest_3`. Splitted project has a special parameter `-PtestSplit=1/3`/`-PtestSplit=2/3`/`-PtestSplit=3/3` so the build can choose only a subset of tests to execute.

  1. … 8 more files in changeset.
Use convention value instead of `getOrElse`

Add --rerun option for the distribution tests

Update wrapper and fix build scripts

In order to fix the Gradleception build (and perf tests)

  1. … 2 more files in changeset.
Fix deprecated usage of java-runtime-resources

This is now replaced by the LibraryElements attribute.

  1. … 2 more files in changeset.
Dogfood native test fixtures

This commit replaces our custom test fixtures with the native "Java test fixtures".

The `TestFixturesPlugin` of our build has been simplified to leverage the native

test fixtures capabilities. Some noticeable changes:

- the `testFixtures` extension has been replaced with regular dependency declaration

- dependencies on test fixtures are now declared using the `testFixtures` keyword

- test fixtures properly declare an API and an implementation, meaning that the

implementation dependencies of test fixtures no longer leak into the compile

classpath of consumers (in particular tests)

  1. … 82 more files in changeset.
Fix typos

Change all subprojects to use 'implementation' dependencies

This includes:

- All projects now explicitly declare all dependencies to other

subprojects. This makes issues more visible, guards for accidental

addition of new dependencies, and leaks much less transitive

dependencies on the compile classpathes.

- All usages of 'runtime' to declare dependencies have been replaced

with 'runtimeOnly'

- All projects are now `java-library` (and declare this explicitly)

- Most remaining Groovy scripts are translated to Kotlin

- The old 'compile' and 'runtime' configurations are not

configured/created anymore for the 'testFixture' and 'integTest'

source sets.

- Some obsolete dependencies (see previous commits) are removed

- 'api' is used scarcely on purpose as the current project structure is

not well designed for this. The projects contain code for several

concerns of the build tool and thus putting complete projects on the

API of others exposes too much. They should be split up along

functional concerns first.

  1. … 110 more files in changeset.