Upgrade to version 2.0.0 causes unexpected Gradle behavior

[bardolf]

After upgrading to version 2.0.0, I encountered some surprising issues. The detekt plugin started failing with very unrelated error. After commenting it out, the liquibase task (updateTestingRollback) was executed, even though it shouldn’t have been — and this behavior did not occur with the previous version of cutterslide plugin.

At this point, I stopped investigating further, as it seems the new version is interfering with Gradle’s expected behavior or lifecycle. I understand this description is quite vague, but creating a minimal reproducible example might take some time. Please let me know if that’s necessary — I’ll prepare one if needed.

Project setup:
Kotlin 2.1.20
Gradle 8.14
Latest versions of detekt and liquibase plugins

Thanks in advance!

[BigMichi1]

a small reproducer will help to understand whats going on

[sam0r040]

Hi @BigMichi1,
we also have problems when updating to 2.0.0, see this PR: springwolf/springwolf-core#1289

For debugging purposes we added the task-graphs with the previous version and then with the 2.0.0 version. From what it looks like, your plugin now enforces execution of the bootTestRun task. We generated the taskgraph by running the build task in springwolf-core module.

Maybe it can help debugging the issue.

[msogrin]

It seems, analyze tasks now depend on all existing tasks that have word "test" in their name.
@BigMichi1 That's a bit too arbitrary behaviour. Is there a reason for this?

[BigMichi1]

I think it is coming from the fixed related to issue #645. Need to check closer. A small reproducer would help, as I have not seen a bad behaviour in my test and production projects.

[msogrin]

Reproducer will be adding custom tasks with names containing substring "test", and analyze tasks will depend on that irrespective of the semantics of the *test* task.

The code doing it is is very clear without the reproducer:

gradle-dependency-analyze/src/main/java/ca/cutterslade/gradle/analyze/AnalyzeDependenciesPlugin.java

Lines 156 to 159 in 3222ed6

	// Depend on all test tasks
	if (project.getTasks().getNames().contains("test")) {
	task.dependsOn("test");
	}

and

gradle-dependency-analyze/src/main/java/ca/cutterslade/gradle/analyze/AnalyzeDependenciesPlugin.java

Lines 184 to 190 in 3222ed6

	// Also depend on all tests and compile test tasks
	final List<String> allTestTasks =
	project.getTasks().getNames().stream()
	.filter(
	name ->
	name.contains("Test") || name.contains("test"))
	.collect(Collectors.toList());

For example, in our project there are tasks created by other plugins with the name of the source set include, e.g. checkstyleTest. But main concern is that our test task running unit tests takes up to 20 minutes (and sometimes fails), so the analysis of dependencies takes unnecessarily long time.

[msogrin]

The concern here is that running test tasks seem to be irrelevant to the task of analyzing compile dependencies.
Old behaviour of just depending on classes and testClasses seems to still be the approach to take.

Depending on tasks that just have an arbitrary substring match is going to cause problems for somebody with "unlucky" setup.