Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Inconsistencies in versions.lock file after running --write-locks across different machines #745

Open
JoshSauter opened this issue Aug 6, 2021 · 3 comments

Comments

@JoshSauter
Copy link

JoshSauter commented Aug 6, 2021

TL;DR: Several of us are working off of the same versions.props file but getting different versions.lock results from running --write-locks

What happened?

When pulling fresh from our master branch (which builds fine on our CI machines), running ./gradlew --write-locks generates a diff for me:

$ ፧ git diff
diff --git a/versions.lock b/versions.lock
index b328cbf..080e267 100644
--- a/versions.lock
+++ b/versions.lock
...
-org.codehaus.jackson:jackson-core-asl:1.9.13 (8 constraints: bd6f3cd0)
+org.codehaus.jackson:jackson-core-asl:1.9.13 (9 constraints: e37e2c84)
...
-org.codehaus.jackson:jackson-mapper-asl:1.9.13 (8 constraints: 1f6c7f7a)
+org.codehaus.jackson:jackson-mapper-asl:1.9.13 (9 constraints: 457b3292)
...

Another teammate running the same command on his local machine results in a different diff where only the hash values of several constraints have changed, and yet another teammate doing the same thing generates no diff from master at all.

What did you want to happen?

I would expect, given the same versions.props file, running ./gradlew --write-locks should generate the same versions.lock file regardless of incidental environmental differences between different machines. Is there some known cause for why we are experiencing this behavior?

@bduisenov
Copy link

Experiencing the same issue where plugin generates different versions.lock files on github ci (linux x86) and locally (macos aarch64)
Screenshot 2023-09-19 at 21 43 39

@bduisenov
Copy link

solved this issue by removing mavenLocal repository

@kerbylane
Copy link

We have been able to address this by purging the local maven cache when it occurs. So it appears to be due to corruption of the local cache.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants