This message was deleted.
# community-support
s
This message was deleted.
e
👋 Hey, @Shaun Reich! I hope I understand your question correctly. The recommendation would be to not reuse project directories between tests. In the documentation you linked, you can see that
@TempDir
is being used. This results in a new project directory for each test execution.
👆 1
c
Give it a working directory that is transient so that nothing is cached. Or run with —no-build-cache
d
👋 personally I'd recommend to use composite builds instead of gradle runner -> it will be much faster
*well keep gradle runner it for failure scenarios and use composite build for happy path
s
oh yeah that's what I overlooked. looking at the sample code i have from gradle's site...i believe i stumbled on a docs bug (or perhaps used non-"current")...the code in the gradle samples i downloaded didn't use that feature. i'll try and track it down to file an issue for it - from
readme.md
:"linkzips/sample gradle plugin kotlin dsl.zip[icondownload[] Kotlin DSL]" :samples-dir promote-projects/gradle/build/git-checkout/subprojects/docs/build/working/samples/install/gradle-plugin gradle version 8.0.1
@Dariusz Kuc yeah, I'm inclined to agree..., from what little I know of the process, but the testing facilities at the plugin creation testing stage seem to lead me down this path and kts docs aren't always where I look. I have much to learn on Gradle still. Structuring build structures around can be challenging in little "gotcha" ways sometimes