search

palantir / gradle-consistent-versions

Compact, constraint-friendly lockfiles for your dependencies
Apache License 2.0
116 stars 14 forks source link

this plugin strobes when writing lock state #392

Open carrino opened 4 years ago

carrino commented 4 years ago

What happened?

I can run this plugin a few times and get different outputs, this causes my circle tests to fail.

example

-org.slf4j:slf4j-api:1.7.28 (61 constraints: a7dcb237)
+org.slf4j:slf4j-api:1.7.28 (60 constraints: 59cdc4b7)

here is another run with the same git repo

-org.slf4j:slf4j-api:1.7.28 (61 constraints: a7dcb237)
+org.slf4j:slf4j-api:1.7.28 (63 constraints: 25fe1336)

3rd run produces the original values of 61 constraints: a7dcb237

What did you want to happen?

Not strobing

iamdanfox commented 4 years ago

I've seen something kinda similar, where CircleCI and local dev disagree, but clearing out the local gradle cache seems to fix it:

find ~/.gradle/caches/modules-2/metadata-* -delete

Does anyone else on your team reproduce this problem? What about CI?

mglazer commented 4 years ago

Do add further flavor to this, what's even odder, is that when I run:

./gradlew why --hash a7dcb237

And then regen locks, and then I run:

./gradlew why --hash 25fe1336

Then take the dependency output from both, and do:

cat deps.txt | wc -l

It's identical.

mglazer commented 4 years ago

Sorry, didn't mean to close. I'm only seemingly able to reproduce this within the CI environment.

carrino commented 4 years ago

I can repro this on my machine. I can run it 5 times and get 3 different counts. Can we just remove the count part, as long as the versions are the same it should be good, no?

iamdanfox commented 4 years ago

@carrino can you share the output from ./gradlew why? Or even just obfuscated?

carrino commented 4 years ago

gw why --hash d7bf4e96 does not consistently return the same output.

some runs have extra lines like 

io.dropwizard.metrics:metrics-healthchecks -> 1.7.25
io.dropwizard.metrics:metrics-jvm -> 1.7.25
dansanduleac commented 4 years ago

We've seen some issues due to gradle resolution recently which might be connected, though mostly around grpc (https://github.com/gradle/gradle/issues/12229). In that investigation we noticed that gradle's caches can become different across machines, with some recording a dependency as having a different version than others.