Common gotcha: multiple configuration targets in a single action

[big-guy]

The problem: https://github.com/gradle/kotlin-dsl/blob/79783269fcec99f858a6ae30bbe1e699f07ffefb/samples/code-quality/build.gradle.kts#L45-L46

When configuring jacocoTestCoverageVerification, we also configured check. When jacocoTestCoverageVerification was made lazy, check was no longer configured to depend on it unless jacocoTestCoverageVerification was realized/executed.

The fix was to separate the configuration steps: https://github.com/gradle/kotlin-dsl/blob/e3fcf65e8e278a36be82316f922afb15525cae9f/samples/code-quality/build.gradle.kts#L41-L48

It's perfectly valid to get the check task and query things from it when configuring jacocoTestCoverageVerification, but any kind of assignment/configuration of check would cause this kind of problem and I think is hard to detect.

We call this out as part of the migration guide: https://docs.gradle.org/nightly/userguide/task_configuration_avoidance.html#sec:task_configuration_avoidance_migration_guidelines

Only mutate the current task inside configuration action. Because the task configuration action can now run immediately, later or never, mutating anything other than the current task will expose flaky-like behavior in your build.

But it may not be clear what "mutate anything" means.

[lacasseio]

I toyed with this change to disallow mutation of a task other than the subject of a lazy configuration: https://github.com/gradle/gradle/commit/e6ba5472f4218c91b7cb08b239b9d85042483677

Do we want to solve it this way?

[lacasseio]

We will fix this issue with a documentation fix for 5.0 and revisit this at a later date: https://github.com/gradle/gradle/pull/6904