7.6.1 breaks gradle-consistent-versions

[CRogers]

Expected Behavior

gradle-consistent-versions is one of our most essential gradle plugins used by 1000s of repos internally at our company.

One half of the plugin takes a versions.props file (example) and applies these constraints to all configurations in all projects. The expectation is that if you add a constraint to this versions.props, it will end up in all your configurations (that it makes sense to apply constraints automatically to).

I have a made a minimal reproducer repository to demonstrate this. It has a project with two configurations that are resolved sequentially by a task, pulling in the constraints from versions.props using gradle-consistent-versions:

# versions.props
com.google.guava:guava = 31.1-jre
junit:junit = 4.12

// build.gradle snippet
configurations {
    one
    two
}

dependencies {
    one 'com.google.guava:guava'
    two 'junit:junit'
}

task resolveBoth {
    doFirst {
        configurations.one.resolve()
        configurations.two.resolve()
    }
}

With Gradle 7.6, if you run ./gradlew resolveBoth both configurations manage to resolve as they both have the constraints loaded from versions.props. See this buildscan when running with Gradle 7.6:

Current Behavior

With Gradle 7.6.1, this same code does not manage to resolve the second configuration (or any configuration after the first). See this buildscan when running with Gradle 7.6.1:

Unfortunately, this causes every repo using gradle-consistent-versions (which is 99% of our repos) to not work with Gradle 7.6.1 (and by extension 8.0.2).

Context

Regressed commit in Gradle

I ran a git bisect between v7.6.0 and v7.6.1 and found this to be the commit that causes the regression:

• "Re-evaluate component configuration metadata if the underlying configuration may have changed" by @big-guy / @ljacomet (from "Reduce memory consumption more" PR).

Buildscans before and at this commit:

• Before @ f492a51: https://scans.gradle.com/s/4kj22kbazgfss
• At regression @ 46e39a3: https://scans.gradle.com/s/4cpltyjyzkif2

gradle-consistent-versions Internals Context

gradle-consistent-versions achieves this constraint propagation by creating a "platform" configuration of dependency constraints in the root project. Another root project configuration rootConfiguration then adds the constraints from the "platform" configuration using a project dependency. (Pretty much) all other configurations extendsFrom this rootConfiguration to ensure they get all the constraints.

You'll notice the regressed 7.6.1 scan is missing the reference to the root project constraint "platform" the successful build using 7.6 had:

Steps to Reproduce

Run ./gradle resolveBoth on CRogers/gradle-7.6.1-gcv-repro@b66a044. The previous commit uses 7.6 and works.

Additionally gradle-consistent-versions has a branch showing it's tests succeeding with 7.6 and failing with 7.6.1.

Your Environment

Build scan URLs:

• 7.6: https://scans.gradle.com/s/ndp5y5z2yhr3g
• 7.6.1: https://scans.gradle.com/s/x52zvtf2qdd4o

[big-guy]

@CRogers thanks for the detailed report. We'll take a look

[jvandort]

@CRogers It looks like this may have been fixed in 8.0.2 and as a result 8.1 (nightly) already by this PR. Would you be able to test with either of these versions to confirm or deny whether this is fixed there?

If so, we can be sure to target the same fix to a 7.x backport if we go down that route.

[CRogers]

@jvandort I can confirm it:

• Doesn't work in 8.0.1
• Works in 8.0.2

[CRogers]

FWIW I also tested against that commit and the parent commit and can confirm it's specifically that which fixes it:

• Fix commit 79a3a14 succeeds: https://scans.gradle.com/s/kume5ghsxogoq
• Parent of above 038ae59 fails: https://scans.gradle.com/s/l7wamyxawwkyi

[jvandort]

@CRogers Thank you for verifying this.

Lets leave this issue open and targeted for 7.x backport, so that if/when we release a 7.7, we can be sure 79a3a14 is included.

[ljacomet]

Resolved with #25166