I’m currently in the progress of improving the user interface of the code coverage plugin (see jenkinsci/code-coverage-api-plugin#203 for details). The basic idea is to improve the navigation so that only two clicks are required to see the actual coverage view for the source files. Additionally, I am reusing some ideas from my warnings plugin: FontAwesome icons, coverage trend with Echarts, Bootstrap 5 cards in the detail view, data-table view for fast source code access, responsive design, etc.
I am also trying to refactor the code base so that in future release we will be able to create delta coverage results for individual elements. That means that we will not only see the changed coverage (as project total) of a pull request but also the coverage of the changed or added lines in a pull request. Using this information we can highlight lines without coverage in pull requests using the GitHub checks API.
The work is still in progress but it might be helpful to get some comments as early as possible. So a simple question: am I on the right way or am I removing or changing some important features? What is also not clear for me from the code base and the existing issues, how are you typically using the plugin?
Are you using a single publishCoverage step or are you calling the coverage step multiple times? In the latter case it is not clear for me how we can create delta reports in the future, since the delta changes with every invocation.
Are you using the heat map that shows the hierarchy of the coverage? Or would it be helpful if we remove that part totally (or replace it with a tree map or sunburst diagram)?
Are you using the aggregation with a tag? Or rephrased: how should the ideal coverage hierarchy look like? Project, Package, File, Class, Method and then Line and Branch as leaf nodes? Or everything flat as possible?
I’m using the coverage configuration that is included in the buildPlugin() pipeline library on ci.jenkins.io. It does not seem to enable the source view.
Thanks. I’ll need to update my secondary job definitions to use the code coverage configuration and retain source code. I have been using the old coverage plugin to browse statement level coverage results. My apologies that I wasn’t aware until a month or two ago that the new coverage plugin also includes the source level coverage report.
Ulli shared a demonstration of the code coverage user experience improvements as part of the UX SIG meeting Sep 15, 2021.
Key elements that Ulli highlighted included:
Color and size coded tree view to rapidly identify large files and poorly covered files
Details view to see line by line coverage details
Usability improvements that are good candidates for Hacktoberfest contributions from others
Ulli agreed to present the project as part of the Contributor Summit Oct 2, 2021 and will highlight ways that new contributors can assist during Hacktoberfest.
Multiple time. The report aggregation is an important feature. Are there any blockers preventing from calculating Deltas upon build completion?
Are you using the heat map that shows the hierarchy of the coverage? Or would it be helpful if we remove that part totally (or replace it with a tree map or sunburst diagram)?
For me any other feasible navigation UX would be fine
BTW: I implemented the building blocks of this PR now. I still need to cleanup the code base and write some more test. But I think it is already feature complete so others can test it. So feel free to check out the pull request and test the new features. If this is too cumbersome I can create beta releases as well.
