If you don’t mind depending on implementation details, you could also switch to Kotlin DSL build scripts, because when syncing with them, IntelliJ is indeed executing a task that you could make depend on your task, but as I said, that is depending on implementation detail of the Gradle plugin in IntelliJ and could of course change anytime.
There’s one big caveat with this plugin - settings are persisting in .idea/workspace.xm even if you remove idea.project.settings block from build.gradle. This side effect makes build process unreliable because it’s no more driven by build script.
// build.gradle
plugins {
id "org.jetbrains.gradle.plugin.idea-ext" version "1.1.8"
}
tasks.register("testest") {
doFirst {
println("TEST doFirst")
}
doLast {
println("TEST doLast")
}
}
// If you remove this block and re-evaluate your project - the "testtest" task would still starting
idea.project.settings {
taskTriggers {
afterSync tasks.getByName("testest")
}
}
You could have made the same setting manually through the IntelliJ UI, so it can hardly remove it as IntelliJ cannot really know whether the setting was done manually or through that plugin. But if you are desperate you can of course use the XML-manipulation triggers of that plugin to remove the afterSync task from the file.
but as I said, that is depending on implementation detail of the Gradle plugin in IntelliJ and could of course change anytime
Can I be sure that this might break only if I dediced to update Gradle to newest versions? I mean, can I depend on the kotlinDslAccessorsReport task (comes from org.gradle.kotlin.dsl.provider.plugins.KotlinScriptRootPlugin) and expect that it will work fine withing the same Gradle version?