Make WordPress Core

Opened 2 months ago

Closed 2 months ago

Last modified 2 months ago

#60476 closed enhancement (fixed)

Upload test coverage report in human-readable HTML format

Reported by: desrosj's profile desrosj Owned by: desrosj's profile desrosj
Milestone: 6.5 Priority: normal
Severity: normal Version:
Component: Build/Test Tools Keywords: has-patch commit
Focuses: Cc:

Description

The Test Coverage workflow currently generates a coverage report XML file using --coverage-clover and uploads that to Codecov for consumption and display.

The coverage workflow only runs currently on every commit, but only some PRs scoped to specific related files being updated. There are some situations where a human-readable format, like HTML, would be very useful.

As an example, I updated the workflow to produce HTML coverage reports for comparing the impact of the change in [57566].

The HTML report could just be uploaded to the workflow as an artifact.

Change History (6)

This ticket was mentioned in PR #6068 on WordPress/wordpress-develop by @desrosj.


2 months ago
#1

  • Keywords has-patch added

#2 @jorbin
2 months ago

  • Keywords commit added
  • Milestone changed from Awaiting Review to 6.5

Love this.

#3 @desrosj
2 months ago

  • Owner set to desrosj
  • Resolution set to fixed
  • Status changed from new to closed

In 57570:

Build/Test Tools: Generate a human-readable HTML coverage report.

This updates the test coverage GitHub Actions workflow to generate a human-readable HTML report in addition to the current machine readable one submitted to Codecov.

Props jorbin.
Fixes #60476.

#5 @swissspidy
2 months ago

What's the advantage of the HTML report over looking at the coverage change on Codecov?

#6 @desrosj
2 months ago

Because of how long the workflow takes (30-40 minutes), we don't currently run it on every push or pull request unless certain configuration files are changed/updated.

But on pull requests, the reports are never pushed to Codecov. In my case, I was changing the version of PHP used to generate the report and needed to compare the outcome to make sure it would not result in a sizable drop in overall coverage. I wasn't able to easily check because the report was XML, and not uploaded anywhere.

From time to time, I consider submitting reports for all PRs. But there's reasonable arguments for both sides and I usually just decide it's better to save the time and resources.

Note: See TracTickets for help on using tickets.