I use the awesome com.autonomousapps.build-health plugin. I also use a convention plugin in an included build which brings in a bunch of kotest libs to the

testImplementation

configuration on all projects, as it's too irritating having to import them every time. Inevitably my top level `build.gradle.kts`'s

dependencyAnalysis.issues.all.sourceSet("test").onUnusedDepencencies.exclude

call looks basically identical to that default

testImplementation

configuration, otherwise

buildHealth

would fail a lot. Is there a cunning way I can grab the

testImplementation

configuration from

buildlogic.kotlin-common-conventions.gradle.kts

and use it in

build.gradle.kts

?

The problem is, there is no "testImplementation configuration from buildlogic.kotlin-common-conventions.gradle.kts". It just gets the same "testImplementation" as anywhere else and adds dependencies to it. Maybe you should either not add those dependencies in the convention plugin if they are not needed everywhere, or make the convention plugin aware of the DAGP and configure it accordingly for those dependencies.

you should either not add those dependencies in the convention plugin if they are not needed everywhere

That's proving way too painful, changing an assertion, adding or removing a test frequently changes the set of kotest libs we depend on, and then the unused ones fail the buildHealth.

make the convention plugin aware of the DAGP and configure it accordingly

I'm unclear how to do that; the build-health plugin "must be applied in a settings script (or to the Settings object)", from where it adds itself to all projects, and the documentation suggests you configure it in the top level

build.gradle.kts

. I don't have access to the

org.gradle.api.Project.dependencyAnalysis

extension DSL in the convention plugin.

It can apply itself to all projects, but iirc I disable that functionality and apply it myself in a convention plugin. But even with the settings plugin applying the project plugin, nothing prevents you to apply it in your convention plugin too (remember a second apply is always just a no-op). And even if you don't want to apply it in the convention plugin, you should always be able to use

pluginManager.withPlugin

and then use

configure<TheExtensionType> { ... }

even without having the type-safe accessor.