I wanted to contribute a fix for an issue in a plugin I'm using that uses nebula-test.
Unfortunately it seems this is not possible right now.
The issue I want to fix is only happening when applying the plugin in a precompiled Kotlin script plugin.
The problem is, that you use a command-line init script to inject the project classes to the test build.
Those init scripts are only applied to the main build, not to the buildSrc build. (https://github.com/gradle/gradle/issues/1055)
To also inject into the buildSrc build, you would need to use a custom Gradle distribution (e. g. let the wrapper / tooling api download the version to test against into a custom folder, then manipulate it before executing the actual test) in which the init script is present in init.d, then it would also be effective on the buildSrc build.
But even then I'm not sure whether it would work, as for the issue to test I need to apply the plugin via plugins-DSL block so that static accessors are generated for it and I think this would not work with just having the plugin in the classpath.
Instead you would probably need to actually build the artifacts, make a maven or ivy repository out of it and configure it as plugin repository using the init script in the custom gradle distribution.
I completely don't know that mechanism, but have you checked it with copyResources("sampleProjects//nexus-at-minimal", "") approach instead of just provide buildFile <<? It should simulate getting the project "from the Internet" and execute the build.
I wanted to contribute a fix for an issue in a plugin I'm using that uses nebula-test. Unfortunately it seems this is not possible right now. The issue I want to fix is only happening when applying the plugin in a precompiled Kotlin script plugin.
The problem is, that you use a command-line init script to inject the project classes to the test build. Those init scripts are only applied to the main build, not to the buildSrc build. (https://github.com/gradle/gradle/issues/1055)
To also inject into the buildSrc build, you would need to use a custom Gradle distribution (e. g. let the wrapper / tooling api download the version to test against into a custom folder, then manipulate it before executing the actual test) in which the init script is present in
init.d
, then it would also be effective on the buildSrc build.But even then I'm not sure whether it would work, as for the issue to test I need to apply the plugin via plugins-DSL block so that static accessors are generated for it and I think this would not work with just having the plugin in the classpath. Instead you would probably need to actually build the artifacts, make a maven or ivy repository out of it and configure it as plugin repository using the init script in the custom gradle distribution.