Is there a way to share configuration files?

[TWiStErRob]

(I'm using Detekt on Gradle)

I have two simple requirements:

1. use the same configuration file (similar to buildUponDefaultConfig or allRules), but with my own custom file (e.g. buildUponConfig = file(...))
2. since I'm "building on" that file, the detekt.yml could be empty, but if it's not, it might be necessary that I disable/enable some additional rules compared to what I'm extending.

Best would be if the yml file can be used from URL, or maybe even from inside a Gradle Plugin JAR file.

Any solutions, hacks are appreciated.

[BraisGabin]

You can set a list of configuration files. If the first one is your default configuration you will get the desired behavior.

About support URL or more complex ways of provide the config file we don't plan to support it. You can create your own gradle task to get the configuration file from anywhere and then feed it to the gradle task as a path.

[TWiStErRob]

You can set a list of configuration files.

That sounds pretty good, somehow I missed that config is a FileCollection, nice design choice!

we don't plan to support it

That's fair, indeed a simple solution with a custom task that creates the base config from URL or classpath is a good enough solution:

tasks.withType<io.gitlab.arturbosch.detekt.Detekt>().configureEach { dependsOn("detektGenerateBaseConfig") }

or I guess even this would work (without explicit dependsOn):

detekt {
    //buildUponDefaultConfig|allRules = true|false
    config.from(tasks.named("detektGenerateBaseConfig"))
    config.from(files("project-specific.yml"))
}

will try these later, thanks for the quick help!

[impossible1770]

An example of simple implementation - https://medium.com/@alex.hrindii/how-to-share-and-publish-detekt-config-14e816d6c8ae

[TWiStErRob]

From a quick read it looks like both of the proposed solutions are doing I/O in the configuration phrase, which is a no-no for Gradle builds. Especially the first one doing a network call.

Btw, the first one only works by accident, as it's missing the doFirst from the Task.register block. So it only copies the file over, because the task is configured when you depend on it, not because it's executed.

You're on a good path though, as I think the config file collection will be resolved at execution time. So if you have a task that downloads/extracts the file and declares it as an output, then a task provider can be added as from source, therefore making it only resolved when necessary and as late as possible.