added coverage multiprocessing config for CI master builds

[jstucke]

supersedes #1310

[codecov-commenter]

Codecov Report

All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 91.84%. Comparing base (ad4d6d8) to head (278c7dc). Report is 11 commits behind head on master.

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #1312      +/-   ##
==========================================
- Coverage   92.23%   91.84%   -0.39%     
==========================================
  Files         379      378       -1     
  Lines       23188    20967    -2221     
==========================================
- Hits        21387    19257    -2130     
+ Misses       1801     1710      -91     

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

[maringuu]

Why not enable it in general? Using sed to change the pyproject.toml does not seem like a good idea to me.

[maringuu]

One could e.g., change the CI script to run pytest as follows:

pytest \
    --cov=. \
    --cov-config=.github/.coveragerc

The .coveragerc would then contain any configuration that diverges from the pyproject.toml.

[jstucke]

Why not enable it in general? Using sed to change the pyproject.toml does not seem like a good idea to me.

Good question! This is more or less a hack. The simple reason is, that with the option multiprocessing enabled, CI builds take 6--8 minutes longer which is a bit too much (see e.g. https://github.com/fkie-cad/FACT_core/actions/runs/12179379759). For the nightly CI build this is not an issue, though.

[jstucke]

One could e.g., change the CI script to run pytest as follows:

pytest \
    --cov=. \
    --cov-config=.github/.coveragerc

The .coveragerc would then contain any configuration that diverges from the pyproject.toml.

Interesting proposal. I'm don't like the idea of using sed either (because it can easily break when the config file changes. I think the return value should indicate when it failed, though?). This on the other hand has the disadvantage that you need to maintain two config files henceforth, though (which shouldn't be that dramatic, since it only very rarely changes).