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
publishCoveragestep 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?