configuration cache causing inconsistent dependency resolution

[mathjeff]

Expected Behavior

When publishing a .pom file for a project, the dependencies listed in the .pom file should be consistent, even if configuration caching is enabled and even if the project depends on "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.0"

Current Behavior

EDIT for Gradle 8: we no longer see inconsistent behavior between cache misses and hits, however the inconsistency remains between CC-enabled and vanilla builds. This probably should be investigated.

I'm observing that when a project depends on "org.jetbrains.kotlinx:kotlinx-coroutines-core:1.5.0", the published .pom file is different based on whether the configuration cache was reused or not.

In particular the difference I'm observing is that the published .pom file lists a dependency of "kotlinx-coroutines-core-jvm" if the build did not load from the configuration cache, but lists a dependency of "kotlinx-coroutines-core" if the build did load from the configuration cache

Context

• This could cause us to publish incorrect .pom files and make it more difficult to validate that we're publishing the right ones
• This could potentially slow builds down by causing us to regenerate any .zip files containing these .pom files

Steps to Reproduce

To reproduce, see https://github.com/mathjeff/gradle-samples/tree/master/configuration-caching-inconsistent-dependency

Your Environment

Build scan with configuration caching disabled: https://scans.gradle.com/s/5wl3snvazev7u

First build scan with configuration caching enabled, which populates the configuration cache: https://scans.gradle.com/s/kmzzkv3lmathq

Second build scan with configuration caching enabled, which loads the configuration cache: https://scans.gradle.com/s/linj4iwsjm574

Thanks!

[github-actions[bot]]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[github-actions[bot]]

This issue has been automatically closed due to inactivity. If you can reproduce this on a recent version of Gradle or if you have a good use case for this feature, please feel free to let know so we can reopen the issue. Please try to provide steps to reproduce, a quick explanation of your use case or a high-quality pull request.

[abstratt]

Since Gradle 8.0, a configuration cache hit and miss behave very similarly, as even on a cache miss, the configuration data is first stored to disk, and then reloaded (a. k. a. load-after-store).

This is no longer reproducible.

[abstratt]

Actually, even though a cache hit and a cache miss are no longer producing inconsistent results dependency-management wise, the difference pointed out by the submitter is still there if you compare a CC run vs a non-CC run. Reopening to investigate.