Pinging @elastic/es-core-infra

I'm not entirely sure if the additional info will be relevant.
Most testkit based tests don't do much more than call gradlew in some way on a sample project, so the exception will just point to where Gradle is invoked. This is similar to how passing -s to ./gradlew on a test failure isn't all that useful.
The details of the failure are available in the test's output e.x. https://gradle-enterprise.elastic.co/s/ipm7fzwgvimrq/tests/orjfcz7hu5lqq-fzbt5s3nffypy

The details we need are not available right now. For example, this failure: https://gradle-enterprise.elastic.co/s/ipm7fzwgvimrq/console-log?task=:build-tools:integTest

The build-tools IT tests are not configured the same as the rest of our tests, specifically around exceptions, which is why we see a truncated stack in that scan.

The build-tools IT tests are not configured the same as the rest of our tests, specifically around exceptions, which is why we see a truncated stack in that scan.

I think Alpar is right here. Usually that stacktrace is going to be something like an UnexpectedBuildFailureException or similar which isn't going to be very relevant to the actual failure of the testkit build. You'd have to pass -S to the GradleRunner argument to ensure we get full stacktraces.

To clarify, I'm not against adding this change to build-tools I'm just not confident it will give us the level of error output we are necessarily looking for in all cases.

You'd have to pass -S to the GradleRunner argument to ensure we get full stacktraces.

We already pass -s in the particular example test that failed, but only the first exception, not all the causes or stack frames were shown. WIthout this change, we can't get any information from GradleRunner. With it, we can at least get failure information passed through if the inner build uses -s (or -S).

I did some more investigation, and discussions with Mark, and see now that this is unfortunately a limitation of GradleRunner. The underlying problem in the earlier linked build was a failure talking to jcenter, but it only shows up in the junit output, not the console. The proposed change here won't fix that, so I'm closing this.