baseline-reproducibility validates that sourceCompatibility is set explicitly #1574
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Generate changelog in
|
iamdanfox
commented
Nov 27, 2020
| getProject(), | ||
| getProject().getRootProject().relativePath(getProject().getBuildFile()), | ||
| JavaVersion.current(), | ||
| getPath())); |
There was a problem hiding this comment.
I broke tracing-java and tried it out, error message looks like this:
1: Task failed with an exception.
-----------
* What went wrong:
Execution failed for task ':tracing-jaxrs:checkExplicitSourceCompatibility'.
> project ':tracing-jaxrs' must set sourceCompatibility explicitly in 'tracing-jaxrs/build.gradle', otherwise compilation will not be reproducible but instead depends on the Java version that Gradle is currently running with (11). To auto-fix, run
./gradlew :tracing-jaxrs:checkExplicitSourceCompatibility --fix
This will automatically add a suggested line (you may need to adjust the number, e.g. to '1.8' for maximum compatibility).
schlosna
reviewed
Nov 29, 2020
...e-java/src/main/groovy/com/palantir/baseline/tasks/CheckExplicitSourceCompatibilityTask.java
Outdated
Show resolved
Hide resolved
fawind
approved these changes
Nov 30, 2020
…ks/CheckExplicitSourceCompatibilityTask.java Co-authored-by: David Schlosnagle <schlosna@gmail.com>
|
Released 3.58.0 |
|
How does this work with https://docs.gradle.org/current/userguide/toolchains.html ? Would I have to specify source compat even if I specify my jvm? |
|
Currently yes - although as soon as they expose a way to extract the toolchain stuff we can update this plugin https://github.com/palantir/gradle-baseline/pull/1574/files#diff-14d5052a9b7ac4fa7663ebf9a728428314e468cc84e6a420f0de25aacaebbc57R81-R82 |
This was referenced Jun 22, 2021
This was referenced Sep 15, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Before this PR
To get a new JVM rolled out fleet wide, we blast out excavators which just dial up the JVM used at CI time. This has been pretty much fine so far as most projects set
sourceCompatibilityexplicitly, but nothing actually validates this right now.Occasionally, this manifests as a question in
#dev-foundry-infraabout the product-dependencies.lock file differing locally on CI (because on CI it's inferring java 15) and locally it's inferring whatever JVM the dev is using, often 11.After this PR
==COMMIT_MSG==
baseline-reproducibility validates that sourceCompatibility is set explicitly using a new
checkExplicitSourceCompatibilitytask.==COMMIT_MSG==
Possible downsides?