I have a composite build with multiple `includeBui...
# gradle
a
I have a composite build with multiple
includeBuilds
. In everyone of those builds I have multiple subprojects with
kotest
as testing framework. I can get the
test
task to pop-up at the root-project level in Gradle. To run the tests from the commandline I need to specifically call
./gradlew my-project:sub-project:test
. My project setup is pretty bare-bones and I never had this before. The only change using composite builds. My settings.gradle.kts of a build:
Copy code
rootProject.name = "asset-mapper"

dependencyResolutionManagement {
    versionCatalogs {
        create("libs") {
            from(files("../../gradle/libs.versions.toml"))
        }
    }
}

include("data")
include("core")
include("server")
include("codegen")
not kotlin but kotlin colored 1
v
"only" change, but relevant change. This is exactly expected
If you do
test
without a path (without any
:
), then all tasks with name
test
in all subprojects that have such a task are executed
Subprojects
Not subbuilds
Not subprojects wthin subbuilds
And this actually has nothing to do with Kotlin, so is off-topic here 😉
a
Thanks for you explanation. I didn't expect
./gradlew test
to work. But I expected to see test under the
asset-mapper
tasks. When I do a project without composite builds i see
verification/test
under the root project. Now I don't see it under the rootproject of the included build (asset-mapper). I didnt know if this wasn't Kotlin. I am understand the reasoning of keeping the channel clean, but it is a little bit annoying to have everything everywhere marked as Not Kotlin. Sometimes you just don't know. I am also part of the Gradle Slack community, but when i post there I get 0 responses....
It works of course with
./gradlew -p modules/asset-mapper test
. But I can not run all
asset-mapper
test tasks from the IntelliJ screen. So maybe it is an IntellliJ issue.
v
Well, by using
-p
you are "standaloning" the included build, and the call
test
to run it everywhere logic works again. But as long as it is treated as included build, you cannot. And the tree in the tool window is from this usage as included build. I doubt JetBrains can or want to change anything there but who knows. 🙂
From Gradle's perspective I'd say it is correct.
a
"And the tree in the tool window is from this usage as included build.". Ah, that makes sense then. I did not expect it. I "assumed" that the IntelliJ tool window sees it as multiple standalone projects.
But we know what everyone says about assumptions.
👌 1