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

Don't apply JUnit reports plugin by default #2355

Merged
merged 2 commits into from
Aug 10, 2022
Merged

Conversation

pkoenig10
Copy link
Member

@pkoenig10 pkoenig10 commented Aug 9, 2022

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:

Screen Shot 2022-08-09 at 2 53 50 PM

It stores test reports in a non-standard place

By default Gradle puts test reports in the following places:

  • JUnit XML test reports in {projectDir}/build/test-results/test
  • HTML test reports in {projectDir}/build/reports/tests/test

But the test reporting plugin moves the JUnit XML test reports to the root project in a custom directory:

  • JUnit XML test reports in {rootProjectDir}/build/junit-reports/junit/{projectName}/test
  • HTML test reports in {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:

  • Our standard CircleCI configs look for files using the regex .*/build/.*TEST.*xml, which will find JUnit XML test reports even in the standard output location.
  • No one appears to be using custom report. Searching internally for the junitReports or junitTaskResults 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.

@changelog-app
Copy link

changelog-app bot commented Aug 9, 2022

Generate changelog in changelog/@unreleased

Type
See change types. Select one:

  • Feature
  • Improvement
  • Fix
  • Break
  • Deprecation
  • Manual task
  • Migration

Description

The JUnits reports plugin is no longer applied by default. Test reports now use the standard output locations from Gradle conventions.

Check the box to generate changelog(s)

  • Generate changelog entry

@iamdanfox
Copy link
Contributor

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.

@bulldozer-bot bulldozer-bot bot merged commit a79fec7 into develop Aug 10, 2022
@bulldozer-bot bulldozer-bot bot deleted the pkoenig/reports branch August 10, 2022 12:30
@svc-autorelease
Copy link
Collaborator

Released 4.154.0

@pkoenig10
Copy link
Member Author

Would you be open to just removing this code entirely? Or do you think it still has value?

@pkoenig10
Copy link
Member Author

Put up a PR for this in #2356 if it's something we want to do.

bulldozer-bot bot pushed a commit to palantir/witchcraft-api that referenced this pull request Sep 2, 2022
###### _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.
This was referenced Sep 2, 2022
CRogers added a commit that referenced this pull request Sep 16, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants