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

Update to Gradle 6.7 and use new toolchains feature for testing on Ja… #1627

Merged
merged 9 commits into from
Nov 16, 2020

Conversation

anuraaga
Copy link
Contributor

…va versions.

Also fixes compatibility with codeNarc and Java 14+

Fixes #891

}
}
}
if (rootProject.findProperty('testAdditionalJavaVersions') == 'true') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I added this like the -java repo has since it doesn't hurt. Here, the tradeoff of test vs build time is so high that it probably doesn't make sense to take advantage of "build once, test many" that we do there, and instead continue to matrix in GitHub resulting in "build + test many" which is fine.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where do we specify this property?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought it could be useful from command line but on second thought guess not so much.

@@ -48,10 +48,6 @@ repositories {

description = 'OpenTelemetry instrumentations for Java'

wrapper {
distributionType = Wrapper.DistributionType.ALL
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We're using -bin in -java per recommendation from Gradle team I believe

}
}
}
if (rootProject.findProperty('testAdditionalJavaVersions') == 'true') {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't see where do we specify this property?

@@ -297,6 +224,12 @@ tasks.withType(Test).configureEach {
testLogging {
exceptionFormat = 'full'
}

if (!isJavaVersionAllowed(JavaVersion.toVersion(11))) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you add comment explaining this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - also made sure it only applies to test task which I guess is more appropriate.

}
}
}
if (rootProject.findProperty('testAdditionalJavaVersions') == 'true') {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thought it could be useful from command line but on second thought guess not so much.

@@ -297,6 +224,12 @@ tasks.withType(Test).configureEach {
testLogging {
exceptionFormat = 'full'
}

if (!isJavaVersionAllowed(JavaVersion.toVersion(11))) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah - also made sure it only applies to test task which I guess is more appropriate.

@@ -67,6 +67,8 @@ tasks.register("testDisabledFieldInjection", Test) {
includes = ["context/FieldBackedProviderFieldInjectionDisabledTest.class"]
}
test.dependsOn(testDisabledFieldInjection)
test.forkEvery 1
tasks.withType(Test) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Noticed that since this approach doesn't override test tasks like the previous one did, some configs get more complicated. I think it's rare so it might be ok but I can go back to the approach of overriding test instead of defining new tasks if it makes more sense.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Found another file that was affected and realized it's probably hard to reason about right now, went back to the approach of using a rule.

Copy link
Member

@trask trask left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

😎

Comment on lines -58 to -59
- name: Set JDK ${{ matrix.java }} home
run: echo JAVA_${{ matrix.java }}_HOME=${{ env.JAVA_HOME }} >> $GITHUB_ENV
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no more JAVA_X_HOME, yay!

Comment on lines +26 to +27
`./gradlew testJava8` or `./gradlew testJava15`. If you don't have a JDK of these versions
installed, Gradle will automatically download it for you.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is so cool

Comment on lines +196 to +198
// We default to testing with Java 11 for most tests, but some tests don't support it, where we change
// the default test task's version so commands like `./gradlew check` can test all projects regardless
// of Java version.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@anuraaga Have you tested that this interplays correctly with test rule below? I think that when java version is requested explicitly by "testJava15", then we should not silently decrease it to satisfy "maxJavaVersion".

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's the main reason I added it here, above the test rule. Though I don't think we have any situation to trigger ambiguity either because we have no case where minJavaVersionForTests is higher than 11. Even if we added it, it should work though.

@iNikem iNikem merged commit d435da4 into open-telemetry:master Nov 16, 2020
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

Successfully merging this pull request may close these issues.

Confusing how to run tests for modules with maxJavaVersionForTests = JavaVersion.VERSION_1_8
3 participants