-
Notifications
You must be signed in to change notification settings - Fork 135
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
Don't apply JUnit reports plugin by default #2355
Conversation
Generate changelog in
|
23b1393
to
a9ff4ed
Compare
I'm fine with this - after the CircleCI 3 upgrade the UI has changed to describe these XML items as 'tests' which I agree is now misleading. |
Released 4.154.0 |
Would you be open to just removing this code entirely? Or do you think it still has value? |
Put up a PR for this in #2356 if it's something we want to do. |
###### _excavator_ is a bot for automating changes across repositories. Changes produced by the roomba/latest-baseline-oss check. # Release Notes ## 4.154.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | The JUnits reports plugin is no longer applied by default. Test reports now use the standard output locations from Gradle conventions. | palantir/gradle-baseline#2355 | ## 4.155.0 _Automated release, no documented user facing changes_ ## 4.156.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Fix BaselineJavaVersion checkstyle configuration on gradle < 7.5 | palantir/gradle-baseline#2360 | ## 4.157.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Make task initialization lazier in the `junit-reports` plugin. | palantir/gradle-baseline#2364 | ## 4.158.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Make the `checkUnusedDependencies` tasks added by `baseline-exact-dependencies` compatible with Gradle's configure-on-demand feature. | palantir/gradle-baseline#2363 | ## 4.159.0 | Type | Description | Link | | ---- | ----------- | ---- | | Improvement | Add an errorprone check and typed annotation for Javax -> Jakarta<br><br>There is a certain class of very problematic cases whereby if you have<br>a method such as the following:<br><br>```<br>myJerseyResource.register(/* this is of type Object */ object);<br>```<br><br>Then if you supply a resource which includes any `javax.ws.rs`<br>annotations on it, then those will not be registered if your Jersey<br>version is 3.x or later (and you'll only find this out at runtime).<br><br>The opposite is also true if you try to supply resources annotated<br>with `jakarta.ws.rs` to Jersey 2.x.<br><br>To address this, this commit attempts to add an errorprone check<br>which lets implementors add an annotation `@ForbidJavax` to methods<br>which have been knowingly migrated to Jakarta EE9 and cannot<br>accept legacy javax types. | palantir/gradle-baseline#2366 | ## 4.160.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Workaround to IDEA-301084 | palantir/gradle-baseline#2368 | ## 4.161.0 | Type | Description | Link | | ---- | ----------- | ---- | | Fix | Reverts a change introduced to baseline-java-version 4.160.0, which was causing failures on multi-project builds. | palantir/gradle-baseline#2369 | To enable or disable this check, please contact the maintainers of Excavator.
The JUnit reports plugin has a couple of problems.
It creates test reports for Gradle tasks
This is very strange. Test reports are intended to be for tests, not for arbitrary tasks. This is confusing in other services that integrate with Gradle test reports (like CircleCI) because it appears that tests have failed when they haven't.
In addition, this causing confusing output when tests are sharded across multiple CI nodes. For true test failures, the failure is only reported once (by the node that ran the test). But Gradle task failures are reported by every node. This leads to confusing output as shown in the screenshot below. We have 5 CI nodes and these errors are reported 5 times (the screenshot just shows 2).
This also creates a ton of garbage output locally. The
build.xml
files are never deleted and this plugin just happily keeps adding 1 until it finds a file name that doesn't exist. Here's an example from one of my local projects:It stores test reports in a non-standard place
By default Gradle puts test reports in the following places:
{projectDir}/build/test-results/test
{projectDir}/build/reports/tests/test
But the test reporting plugin moves the JUnit XML test reports to the root project in a custom directory:
{rootProjectDir}/build/junit-reports/junit/{projectName}/test
{projectDir}/build/reports/tests/test
There's no good reason to do this. It just makes it hard for devs to understand how our infrastructure works. This is especially confusing because documentation for other tools often references the standard behavior. For example, in the CircleCI docs.
I don't anticipate this being a disruptive change for a couple reasons:
.*/build/.*TEST.*xml
, which will find JUnit XML test reports even in the standard output location.junitReports
orjunitTaskResults
Gradle extension config, I find just a single use.I'm strongly inclined to just remove this JUnit reporting plugin altogether. It appears to be wildly over-engineered to support arbitrary/custom reports, unnecessarily messes with standard Gradle conventions, and is confusingly called "junit reports" even though these reports are definitely not related to JUnit.