From mobile apps to microservices, from small startups to big enterprises, Gradle helps teams build, automate and deliver better software, faster.

Gradle Community

I have a multi-project build which adds detekt to each project using a convention plugin.

```// in build-logic/**/base-conventions.gradle.kts

plugins {
   id("io.gitlab.arturbosch.detekt")
}

// tried adding this here
tasks.findByName("check")?.run {
   dependsOn.removeIf { (it as? Task)?.name == "detekt" }
   dependsOn(tasks.named("detektMain"))
   dependsOn(tasks.named("detektTest"))
}```
I also tried to configure `check` from the root project
```// ./build.gradle.kts

tasks.named("check").configure {
   dependsOn.removeIf { (it as? Task)?.name == "detekt" }
}```
Neither approach worked so far

You probably need to use `tasks.check { setDependsOn(...) }`

Hmm.. still no luck. Perhaps its not added directly to check, but to some other task run by check. I'll try to print the task graph or something. :slightly_smiling_face:

Casting to `Task` was wrong. Shouldve been `TaskProvider`

• `DetektPlugin#apply` directly unconditionally calls `project._registerDetektPlainTask_(extension)`
• `project._registerDetektPlainTask_(extension)` directly unconditionally calls `DetektPlain#registerTasks(extension)`
• `DetektPlain#registerTasks(extension)` directly unconditionally calls `project._registerDetektTask_(extension)`
• `project._registerDetektTask_(extension)` directly unconditionally calls `tasks.matching { it.name == LifecycleBasePlugin.CHECK_TASK_NAME }.configureEach { it.dependsOn(detektTaskProvider) }` 
So it is indeed `check` which depends on `detekt`.
And the dependency should already be there.

ended up with
```
tasks.named("check").configure {
   this.setDependsOn(
      this.dependsOn.filterNot {
         it is TaskProvider&lt;*&gt; &amp;&amp; it.name == "detekt"
      } + tasks.named("detektMain") + tasks.named("detektTest"),
   )
}```
which is working now :slightly_smiling_face:

If you don't want to ever execute `detekt` you could also simply disable it :slightly_smiling_face:

is it better to use `tasks.matching { it.name == LifecycleBasePlugin.CHECK_TASK_NAME }.configureEach` over `tasks.named("check")`?

No.
If you know the task is there, use `named`

`named` fails if the task is not there, `matching` just ignores.

I want check to run another task than the default one :slightly_smiling_face: so I cant remove it completely.

While actually `tasks.matching` like that should heavily disturb task-configuration avoidance

&gt; I want check to run another task than the default one :slightly_smiling_face: so I cant remove it completely.
?

another than the default `detekt` , I want to use `detektMain`  and `detektTest` instead :slightly_smiling_face:

I got that, but I don't understand that as answer to my suggestion

```tasks.detekt { enabled = false }
tasks.check { dependsOn(tasks.detektMain, tasks.detektTest) }```

Btw. while in Kotlin DSL, you don't need `named`, you can just use the accessors which internally use `named`. Just in Groovy DSL you should use `named` instead to maintain task-configuration avoidance.

Oh.. that seems a bit more convenient. :slightly_smiling_face:

That's what I meant, if you don't intend to call `detekt` at all, not even manually

Correct. I dont intend to do that :+1: Thanks a lot. That ended up way better than what I was about to push :100: