I'm testing using `detektMain` on my project. One of my library modules generates code in `build/ge...

# detekt

[eygraber]

I'm testing using detektMain on my project.

One of my library modules generates code in build/generated/myapp/kotlin which is added as a source set to main like so:

extensions.getByType<LibraryExtension>().sourceSets {
  named("main") {
    java {
      srcDir(layout.buildDirectory.file("generated/myapp/kotlin"))
    }
  }
}

However, I don't want detekt to look at generated files. How can I prevent that?

[chao]

https://detekt.github.io/detekt/configurations.html#rule-sets-and-rules You can check out this section

[chao]

By the way, it feels like including srcDirs from build/generated is an anti-pattern for Gradle. Usually we generate a specific source set outside the build directory

[eygraber]

Does that mean I'd have to exclude that directory for each specific rule? I don't want any analysis done on those files at all.

I mostly modeled my code generator off of SqlDelight and other libraries that I use, which put generated source in the build directory.

[chao]

Actually Detekt.source is of type fileTree and Detekt task itself is a SourceTask, so we should be able to configure the specific task’s source to exclude some directory, or even invoke SourceTask.exclude. I have not tried it yet but I have high confidence that this would work

[eygraber]

I've tried a few variations of:

detekt {
  source.asFileTree.matching {
    exclude { "build" in it.path }
  }
}

But it's still including those files

[chao]

Did you configure that specific DetektTask?

[chao]

detekt {} is to configure the detekt extension

[eygraber]

Yup, that was it, thanks!

[ephemient]

relevant (since you mentioned detektMain): https://github.com/detekt/detekt/issues/4127

[Gama11]

@chao can you elaborate a bit on why you think it's an antipattern for gradle? I ask because I've done the same thing (generating some stuff into src/main and then .gitignoring that) when migrating our project from maven to gradle because it seemed easier in some regards, but I thought it's a hack I should clean up eventually... :)

[eygraber]

@ephemient I encountered that as well. I used the overload that takes a predicate and it works.

[chao]

@Gama11 My concern is generating source code into build/ and adding folders under build/ into source set.

[chao]

The problem with that is files under build are cleanable, and as plugin authors, we sometimes delete files under build folder to prevent cacheability issues (Sync as a standard task in Gradle, works in a similar fashion https://docs.gradle.org/current/dsl/org.gradle.api.tasks.Sync.html)

This also fits semantic meanings of src and build

[Gama11]

not sure why it's a problem that it's cleanable? unless you check in the generated code?

[chao]

In my context, moving code generation into published artifacts to speed up build time. And we had ran into numerous cacheability issues with generated code (So that diffing the generated code helps us debug this further).

[chao]

Probably it seems like an anti-pattern in my local context 😢

[eygraber]

Yeah it's probably context dependent

[ephemient]

published artifacts don't need the generated code to be checked in? just publish the .jar and -sources.jar and everything should just work