CIConfigIntegrationTests.kt

Clone Tools
  • last updated a few seconds ago
Constraints
Constraints: committers
 
Constraints: files
Constraints: dates
Distributed test

  1. … 91 more files in changeset.
Distributed test

  1. … 92 more files in changeset.
Clean up Kotlin DSL

  1. … 44 more files in changeset.
Run docsTest as part of the functional test coverage (#13048)

  1. … 5 more files in changeset.
Fix TC configuration integration test

  1. … 1 more file in changeset.
Fix TC configuration integration test

Fix TC configuration integration test

Fix TC configuration integration test

Remove Experimental Windows 10 pipelines

  1. … 1 more file in changeset.
Automate subproject generation (#11800)

This resolves https://github.com/gradle/gradle-private/issues/1462

Previously, when we want to add a new subproject, we need:

- Add the subproject directory.

- Include it in `settings.gradle.kts`.

- Include it in `CIBuildModel` with correct test settings.

This is somewhat cumbersome.

This change automates the new project generation:

- Add the subproject directory and include it in `settings.gradle.kts`.

- Run `./gradlew generateSubprojectsInfo`.

- Commit the updated JSON description file.

The JSON description file exists in `.teamcity` directory so both TeamCity and root project can read it.

  1. … 11 more files in changeset.
Refine test

Refine test

Automate subproject generation

  1. … 12 more files in changeset.
Automate subproject generation

  1. … 12 more files in changeset.
Monitor file handle leaking on Windows

This commit is a follow-up of #11900

There're several extra build steps on Windows build:

- ATTACH_FILE_LEAK_DETECTOR attach the java agent to daemon JVM,

which monitors open file handles and listens a port, writes the

port into ports.txt.

- DUMP_OPEN_FILES_ON_FAILURE runs only when previous build steps fail.

It reads ports.txt and sends HTTP requests to daemons to get the

leaking file handles.

  1. … 4 more files in changeset.
Monitor file handle leaking on Windows

This commit is a follow-up of #11900

There're several extra build steps on Windows build:

- ATTACH_FILE_LEAK_DETECTOR attach the java agent to daemon JVM,

which monitors open file handles and listens a port, writes the

port into ports.txt.

- DUMP_OPEN_FILES_ON_FAILURE runs only when previous build steps fail.

It reads ports.txt and sends HTTP requests to daemons to get the

leaking file handles.

  1. … 4 more files in changeset.
windows file leak detector

  1. … 4 more files in changeset.
Revert "Monitor file handle leaking on windows (#11900)"

This reverts commit eb67479877425636589b96cd3cae065ae734ce77.

  1. … 4 more files in changeset.
Revert "Monitor file handle leaking on windows (#11900)"

This reverts commit eb67479877425636589b96cd3cae065ae734ce77.

  1. … 4 more files in changeset.
Monitor file handle leaking on windows (#11900)

We've been bitten by file leaking for a long time. This PR uses [the custom fork](https://github.com/blindpirate/file-leak-detector/) with some changes:

- Original file leak detector only supports printing open file handles at shutdown time, but for Gradle daemon this doesn't work. We want to print all open file handles at the end of every build. We achieve this goal by setting up a tiny http server inside the daemon JVM and sending HTTP requests to notify it.

So the whole monitor process is:

- Replace `gradle.properties` with `gradle.windows.properties`, which has the javaagent JVM startup parameter.

- The agent looks for an available port to listen, then prints the port number to `port.txt` file.

- After each build, a script runs `java gradle/DumpOpenFiles.java`, which reads the port number and sends HTTP request to daemon. The generated file handle dump file will be at the project directory for further investigation if any file leaking happens.

  1. … 4 more files in changeset.
Monitor file handle leaking on windows (#11900)

We've been bitten by file leaking for a long time. This PR uses [the custom fork](https://github.com/blindpirate/file-leak-detector/) with some changes:

- Original file leak detector only supports printing open file handles at shutdown time, but for Gradle daemon this doesn't work. We want to print all open file handles at the end of every build. We achieve this goal by setting up a tiny http server inside the daemon JVM and sending HTTP requests to notify it.

So the whole monitor process is:

- Replace `gradle.properties` with `gradle.windows.properties`, which has the javaagent JVM startup parameter.

- The agent looks for an available port to listen, then prints the port number to `port.txt` file.

- After each build, a script runs `java gradle/DumpOpenFiles.java`, which reads the port number and sends HTTP request to daemon. The generated file handle dump file will be at the project directory for further investigation if any file leaking happens.

  1. … 4 more files in changeset.
Detect file handle leaking on Windows

  1. … 4 more files in changeset.
Fix tests

  1. … 2 more files in changeset.
Split integMultiVersionTest by subprojects

Now we split integMultiVersionTest in the same way as other tests.

  1. … 4 more files in changeset.
Upgrade TeamCity DSL to 2019.2, kotlin to 1.3.61

  1. … 43 more files in changeset.
Upgrade TeamCity DSL to 2019.2, kotlin to 1.3.61

  1. … 43 more files in changeset.
Split allVersionsCrossVersionTest and allVersionsMultiIntegTest

  1. … 2 more files in changeset.
Split allVersionsCrossVersionTest and allVersionsMultiIntegTest

  1. … 2 more files in changeset.
Automate build buckets generation

This commit automate the build buckets generation by using

historical build time data, so that we can have many evenly

distributed build buckets.

    • -94
    • +124
    ./CIConfigIntegrationTests.kt
  1. … 16 more files in changeset.
Automate build buckets generation

This commit automate the build buckets generation by using

historical build time data, so that we can have many evenly

distributed build buckets.

    • -94
    • +124
    ./CIConfigIntegrationTests.kt
  1. … 16 more files in changeset.