GitHub: Coverity scan enabling (Lnx) #3357
Conversation
vyevtyus
requested review from
Alexsandruss,
ahuber21,
ethanglaser,
homksei,
icfaust and
napetrov
as code owners
|
for patch -
|
There was a problem hiding this comment.
2 main things I would like clarified:
- How are we going to go about testing changes in the coverity system (especially with new patches, verify functionality etc.)
- How can we get an understanding of the issues in the patch such that it can be understood and analyzed my maintainers before merging, could we add some sort of guide what to look for here for reference?
.github/workflows/coverity.yml
Outdated
| mkdir cov-linux64-tool | ||
| tar -xzf cov-linux64-tool.tar.gz --strip 1 -C cov-linux64-tool | ||
| cd cov-linux64-tool/config | ||
| git apply --check ${GITHUB_WORKSPACE}/.github/fix.coverity-2024.12.patch |
There was a problem hiding this comment.
Can you talk about the maintainability of this patch? I expect this will need to be updated on a regular basis, and do we have a contingency plan for testing and verifying changes to the patch?
There was a problem hiding this comment.
Taking into account low frequency of client versions update and almost zero difference between compiler configs between versions (according to our experience), I would say that we'll probably need to review the patch relevance once every 6-12 month. As for plan, currently there is no strategy on maintainability and it worth to be discussed. We may have patch application optional - in this case it's irrelevance won't broke the scan in case of tool client version update. Besides, the newer client version we use, the better Intel compiler support is implemented in it (theoretically).
Co-authored-by: Ian Faust <icfaust@gmail.com>
Co-authored-by: Ian Faust <icfaust@gmail.com>
Co-authored-by: Ian Faust <icfaust@gmail.com>
|
| schedule: | ||
| - cron: '0 21 * * *' | ||
| # allows to reuse this workflow | ||
| workflow_call: |
There was a problem hiding this comment.
Using workflow_call is the recommended way to trigger this CI step for validating updates to coverity? Still trying to figure out how we will validate new patches.
There was a problem hiding this comment.
workflow_call is not a way to trigger the scan. It provides a possibility to include this scan as step into CI/Nightly if needed. If there are no such plans at the moment, we can remove this.
If someone needs or wants to test a new patch, it's enough to create a fork, make necessary changes to the patch, disable results uploading stage, and run a scan for that fork. After the build step completes, the percentage of captured compilation units, displayed at the end of the log, will indicate whether the new patch is good enough.
There was a problem hiding this comment.
I think such a pipeline could be added to this PR which checks for changes in the patch file and runs a specially triggered version of the current pipeline which doesn't upload (by additional logic checks in the current PR).
4 participants
Description
This PR introduces workflow for Coverity scan on the main oneDAL branch. The scan is implemented for Linux platform only, but may be extended for Windows as well, if needed. Results uploading is configured into https://scan.coverity.com/projects/uxlfoundation-onedal (please, request access in advance). Taking into account the size of the project and limitations described in https://scan.coverity.com/faq#frequency, the maximum number of weekly builds for the project is 14 (2 per day), so it was decided to set up schedule (to scan once a day) instead of scanning after every push into the main branch, but it remains configurable. Also, there is a possibility to reuse this workflow, e.g. in case there are plans to include the scan into Nightly.
Patch file placed in .github/ reflects changes in Coverity configuration files, needed to reach 85% compilation units capturing (CCUs) level as a requirement of scan.coverity.com to perform analysis (there is a lack of DPCPP compiler support by Coverity analysis).
Checklist:
Completeness and readability
Testing