1.18.1: Bazel based test runs fail in the KtTestCompiler

[davidburstromspotify]

When using Bazel as a test runner for Detekt extensions, the tests fail with

    => java.lang.ExceptionInInitializerError
       io.github.detekt.test.utils.CompileExtensionsKt.compileContentForTest(CompileExtensions.kt:14)
       io.github.detekt.test.utils.CompileExtensionsKt.compileContentForTest$default(CompileExtensions.kt:10)
       io.gitlab.arturbosch.detekt.test.RuleExtensionsKt.lint(RuleExtensions.kt:31)
       io.gitlab.arturbosch.detekt.test.RuleExtensionsKt.compileAndLint(RuleExtensions.kt:27)
       [...]
     Caused by: java.nio.file.FileSystemNotFoundException
       jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getFileSystem(ZipFileSystemProvider.java:169)
       jdk.zipfs/jdk.nio.zipfs.ZipFileSystemProvider.getPath(ZipFileSystemProvider.java:155)
       java.base/java.nio.file.Path.of(Path.java:208)
       java.base/java.nio.file.Paths.get(Paths.java:97)
       io.github.detekt.test.utils.ResourcesKt.resourceAsPath(Resources.kt:21)
       [...]

The difference between Gradle and Bazel in this case is that Gradle provides the test classes as file paths, whereas Bazel provides them in a JAR.

Since we're not using resource based tests in our consuming project, it's easy enough to fix this by deferring the root path calculation.

--- a/detekt-test-utils/src/main/kotlin/io/github/detekt/test/utils/KtTestCompiler.kt
+++ b/detekt-test-utils/src/main/kotlin/io/github/detekt/test/utils/KtTestCompiler.kt
@@ -23,7 +23,7 @@ import java.nio.file.Path
  */
 internal object KtTestCompiler : KtCompiler() {
 
-    private val root = resourceAsPath("/")
+    private val root by lazy { resourceAsPath("/") }
 
     fun compile(path: Path) = compile(root, path)
 

The question is, if we fix this, when might this be available in an upstream release?

[cortinico]

The difference between Gradle and Bazel in this case is that Gradle provides the test classes as file paths, whereas Bazel provides them in a JAR.
Since we're not using resource based tests in our consuming project, it's easy enough to fix this by deferring the root path calculation.

Shouldn't we look into processing the resources as a JAR to address the Bazel scenario as well rather than excluding it?

The question is, if we fix this, when might this be available in an upstream release?

Discussed offline: This fix/patch will end up in Detekt 1.19.0 as it's basically a fix and not a regression 👍

[davidburstromspotify]

The proposed patch fixes a real world issue. Maybe the resources based testing in Bazel can be fixed when it is a real world issue :)