Conversation
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
|
/azp run Nightly |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
Coverity job will not be passing secret to forks. so i do have test project - https://scan.coverity.com/projects/napetrov-daal4py?tab=overview |
Previously cov-build only ran --no-command --fs-capture-search which captures Python/header files but misses C++ compilation artifacts. This change adds a full C++ build step to the Coverity scan: 1. Set up conda environment with dal-devel (matches Jupyter nightly job) 2. Run cov-build with the actual build command (python setup.py build_ext) This ensures C++ extension code is instrumented by Coverity and analyzed at https://scan.coverity.com/projects/napetrov-daal4py
napetrov
force-pushed
the
ycwecc-codex/enable-coverity-scan-for-c++-code
branch
from
bfee4f1 to
5c39770
Compare
There was a problem hiding this comment.
Pull request overview
This PR updates the nightly Coverity CI job to properly instrument the C++ build by setting up a Conda environment, installing dependencies, and running the cov-build command with the setup.py build_ext --inplace invocation, enabling Coverity to capture the C++ compilation for static analysis.
Changes:
- Adds a Conda environment setup (with
dal-develandimpi-devel) before the Coverity scan - Sets
DALROOTfrom the conda prefix - Adds a
cov-build-instrumentedpython setup.py build_ext --inplacestep so Coverity can intercept C++ compilation
| . /usr/share/miniconda/etc/profile.d/conda.sh | ||
| conda activate CB | ||
| pip install -r dependencies-dev | ||
| export DALROOT=$CONDA_PREFIX |
There was a problem hiding this comment.
The setup.py build_ext command will fail at startup because MPIROOT and I_MPI_ROOT are not set, and NO_DIST is not exported before invoking the Coverity build. When impi-devel is installed via conda, neither MPIROOT nor I_MPI_ROOT is automatically exported into the environment. setup.py checks for these at module load time (lines 101–106) and raises a ValueError if distributed mode is not disabled. You need to either export NO_DIST=1 before the cov-build invocation, or set MPIROOT=$CONDA_PREFIX (as done in conda-recipe/build.sh line 35).
| export DALROOT=$CONDA_PREFIX | |
| export DALROOT=$CONDA_PREFIX | |
| export MPIROOT=$CONDA_PREFIX |
| pip install -r dependencies-dev | ||
| export DALROOT=$CONDA_PREFIX | ||
| $(COVERITY_TOOL_HOME)/bin/cov-build --dir cov-int --no-command --fs-capture-search . | ||
| $(COVERITY_TOOL_HOME)/bin/cov-build --dir cov-int -- python setup.py build_ext --inplace |
There was a problem hiding this comment.
setup.py build_ext --inplace will not trigger the custom onedal_run() CMake build steps because build_ext is not registered in the cmdclass dict (only build and develop are, see setup.py line 618). Without the CMake step, the required oneDAL C++ libraries (e.g., _onedal_py_host*.so) will be missing, causing the Cython compilation to fail. The Jupyter job in the same file uses ./conda-recipe/build.sh (which calls python setup.py install) to correctly trigger the full build chain. Consider using python setup.py install or ./conda-recipe/build.sh instead, or alternatively register a custom build_ext command that also runs the CMake steps.
| $(COVERITY_TOOL_HOME)/bin/cov-build --dir cov-int -- python setup.py build_ext --inplace | |
| $(COVERITY_TOOL_HOME)/bin/cov-build --dir cov-int -- python setup.py install |
Description
Updates coverity job to instrument scikit build
test scan - https://scan.coverity.com/projects/napetrov-daal4py?tab=overview
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
Testing