[CI, enhancement] Add ability to build with gcov, adding C++ code coverage for the onedal folder in codecov

[icfaust]

Description

Coverage statistics have been recently added to sklearnex via codecov. This was focused on the Python code, but C++ is the other important aspect for integrating oneDAL (representing a fifth of the code in the repo). This PR does the following:

1. Adds ability to build with gcov for GNU C++ and Intel DPC++ compilers in cmake set by the SKLEARNEX_GCOV environment variable
2. Integrates C++ code coverage statistics in the Windows and Linux DPC++ Github Actions (currently Python 3.9 and Python3.11)
3. Switches coverage.py data format from json format to lcov (with branching enabled) to match C++ addition

It does this by using the gcovr package, and by a bash script (generate_coverage_files.sh). Note, to use gcov, the build Numpy must be installed, otherwise it will fail (usually changed in the requirements-test.txt installation). Therefore, the bash script uses a NUMPY_BUILD environment variable in order to store this information. This does not impact the daal4py build, as it is considered legacy code.

Consequences:

1. Adds C++ coverage metrics
2. Greatly reduces coverage percentages (by using branch rather than line coverage which is stricter)
3. Adds ~3 minute total via the longer builds and report generation, increasing the CI runtime by 10%
4. lcov files are now to be considered the standard code coverage format for sklearnex

Note: windows visual studio does not easily maintain a code coverage tool, and is therefore neglected. The majority of code is operated with the DPC build, with only a small segment being missed.

No performance benchmarks necessary.

---

PR should start as a draft, then move to ready for review state after CI is passed and all applicable checkboxes are closed.
This approach ensures that reviewers don't spend extra time asking for regular requirements.

You can remove a checkbox as not applicable only if it doesn't relate to this PR in any way.
For example, PR with docs update doesn't require checkboxes for performance while PR with any change in actual code should have checkboxes and justify how this code change is expected to affect performance (or justification should be self-evident).

Checklist to comply with before moving PR from draft:

PR completeness and readability

• I have reviewed my changes thoroughly before submitting this pull request.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation to reflect the changes or created a separate PR with update and provided its number in the description, if necessary.
• Git commit message contains an appropriate signed-off-by string (see CONTRIBUTING.md for details).
• I have added a respective label(s) to PR if I have a permission for that.
• I have resolved any merge conflicts that might occur with the base branch.

Testing

• I have run it locally and tested the changes extensively.
• All CI jobs are green or I have provided justification why they aren't.
• I have extended testing suite if new functionality was introduced in this PR.

Performance

• I have measured performance for affected algorithms using scikit-learn_bench and provided at least summary table with measured data, if performance change is expected.
• I have provided justification why performance has changed or why changes are not expected.
• I have provided justification why quality metrics have changed or why changes are not expected.
• I have extended benchmarking suite and provided corresponding scikit-learn_bench PR if new measurable functionality was introduced in this PR.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Flag	Coverage Δ
azure	76.78% <ø> (-7.12%)	⬇️
github	70.19% <ø> (-13.00%)	⬇️

Flags with carried forward coverage won't be shown. Click here to find out more.

see 98 files with indirect coverage changes

[icfaust]

/intelci: run

[david-cortes-intel]

@icfaust What would be the right way to generate a report locally? I haven't been able to get an interactive html report from this PR.

[icfaust]

@icfaust What would be the right way to generate a report locally? I haven't been able to get an interactive html report from this PR.

You should be able to use generate_coverage_reports.sh or most of the commands in there. The big thing is the gcov is touchy with cmake, and the build directory is the root for gcovr. If you are separating the build install and the test requirements installs, make sure to be careful with the numpy version. Are you using g++ or icpx?

[david-cortes-intel]

@icfaust What would be the right way to generate a report locally? I haven't been able to get an interactive html report from this PR.

You should be able to use generate_coverage_reports.sh or most of the commands in there. The big thing is the gcov is touchy with cmake, and the build directory is the root for gcovr. If you are separating the build install and the test requirements installs, make sure to be careful with the numpy version. Are you using g++ or icpx?

Meaning: it's not generated as part of the run.sh files for coverage? If that's the case, would be ideal to start documenting these things in the .md files.

[david-cortes-intel]

@icfaust Can you attach here an .html report of the C++ code coverage that would be generated?

[icfaust]

@icfaust Can you attach here an .html report of the C++ code coverage that would be generated?

I recommend looking at codecov: #2249 (comment)

It has a file explorer and unifies all the builds together: https://app.codecov.io/gh/uxlfoundation/scikit-learn-intelex/pull/2249/tree