KT-64377 use Java Test Suites for Gradle integration tests

[adam-enko]

Restructure Gradle Integration tests to use Java Test Suites

• create a test suite for each project under test (a separate test suite helps with Gradle caching, task avoidance, and parallelising)
• update GitHub Action steps to run specific test-suite tasks
• disable caching integration test tasks due to dependency on Maven Local publishing (this will be fixed in KT-64377 Maven dev publish #3433)

Contains:

• KT-64377 - remove gradle wrapper files for integration test projects #3418
• KT-64377 - automatically download and setup Android SDK in Gradle Integration Test #3419
• KT-64377 - Update Dokka build properties #3420
• KT-64377 disable explicit api in test utils #3428

[adam-enko]

I don't know why Publish preview to web (S3) / kotlinx-serialization is failing, the error seems unrelated.

    * Where:
    Script '/tmp/junit4521301651836114530/project/gradle/native-targets.gradle' line: 102

    * What went wrong:
    A problem occurred evaluating script.
    > No signature of method: static java.util.Arrays.compare() is applicable for argument types: ([Ljava.lang.String;, [Ljava.lang.String;, native_targets_1w0e7ne0z5gs2bcbvygztfbme$_run_closure1$_closure5$_closure8) values: [[1, 9, 0], [1, 9, 20], native_targets_1w0e7ne0z5gs2bcbvygztfbme$_run_closure1$_closure5$_closure8@64766701]

I guess this is the code that's failing https://github.com/Kotlin/kotlinx.serialization/blob/8baa04b4259274305eea6b02f5c5590b44ea126c/gradle/native-targets.gradle#L102

Is the test important?

---

EDIT I saw the KDoc on NonCacheableIntegrationTest and remembered about DOKKA_TEST_OUTPUT_PATH. I've added DOKKA_TEST_OUTPUT_PATH as a test-task input/output, so Gradle should re-run the tasks if required.

---

EDIT2

DOKKA_TEST_OUTPUT_PATH is important, but isn't relevant.

The actual problem is because KxS uses Arrays.compare(T[] a, T[] b, Comparator<? super T> cmp) in a Gradle script, but this is only available on JVM 9+. Prior to this PR all integration tests used JVM11, because that is what Coroutines required, and there was no way to set a javaLauncher per test. In this PR I split up the tests, and so Coroutines needed JVM11 but the others could use the default version. Or so I thought... and actually KxS needs JVM11 too.

Using JVM11 to test KxS is a simple fix, that's now implemented. The test should pass now.

[IgnatBeresnev]

Sorry, but I strongly believe that check or test or any other similar basic task should not run anything as heavyweight / complicated as all of Dokka's "integration tests".

I don't know if the reworked tests have the same problems as the current ones, but now you are unable to run integration tests locally if you

• didn't initialize git submodules (not done by default, fails with obscure errors like "unable to find a file")
• don't have Android SDK installed (the android test is executed regardless)
• have less than 32gb of ram
• can't leave some hungry process running for 1h (I had to close my IDEs and chrome to run tests when I had 16gb of ram, and it still didn't work half the time)

If you do manage to run these tests and they fail, it's not obvious at all to external contributors or members without context as to what to do about it and how to fix it (especially if it's a false positive or is expected), so for them it's virtually useless.

Integration tests were run by default before, and it was very annoying for the reasons outlined by Oleg. I ran pretty much every build with test -x integrationTest, but it might be impossible after this change because there's no taskgraph between tasks of included builds (all the addDependencyOnSameTasksOfIncludedBuilds calls), so they will be run whether you want it or not

---

As a side note (not a requirement or a comment for this PR specifically, there's no need to implement it).

Ideally, I think the workflow should be the following:

1. run basic checks locally (<= 1-2 min)
2. push a commit that triggers more complex CI checks (smoke, <= 30m), merge the PR
3. even more complex CI checks are triggered for every commit in master / nightly / manually (>= 30m)

This idea was mentioned in #2925 (comment):

The current integration tests take 1h+ to run, which is painful in PRs and hogs CI agents. There should be a a differentiation between "full tests" that run everything, and their subset in the form of "smoke tests", that only test specific versions (maybe only the latest) or projects (maybe only 2 out of 10 user projects). Smoke tests are intended to be run for commits in PRs, and full tests - overnight or triggered manually.

[ALikhachev]

In general, LGTM 👍