Closes #22118: Collect coverage from parallel test workers

[pheus]

Fixes: #22118

Configure coverage.py to collect data from Django's parallel test workers.

The coverage job currently runs the Django test suite with --parallel, which uses worker processes. This change adds coverage.py multiprocessing configuration, moves the measured source/report settings into pyproject.toml, and combines the per-process coverage data before generating the report.

This keeps the faster parallel test run while making the remaining coverage job more accurate.

[pheus]

@claude /review Only report on issues of potential concern; we don't need commentary on anything that doesn't require further consideration.

[github-actions]

Claude finished @pheus's task in 2m 16s —— View job

---

Review

• Read changed files and diff
• Analyze for potential issues
• Post review findings

---

The approach is correct — concurrency = ["multiprocessing"] + parallel = true + coverage combine is the documented way to collect coverage across Django's --parallel worker processes. A few things worth checking:

sigterm = true requires coverage.py >= 7.6.0

pyproject.toml line 33. The CI installs coverage without a version pin (pip install coverage tblib), so this is fine in practice, but if the installed version is older (< 7.6.0), the key is silently ignored and workers killed via SIGTERM will lose their coverage data without any warning. Consider adding a minimum version constraint, e.g. pip install "coverage>=7.6" tblib.

coverage combine will fail if no .coverage.* files exist

.github/workflows/ci.yml line 129. With parallel = true, coverage.py writes .coverage.<host>.<pid>.<rand> files — including for the main process. If the test run exits before any coverage data is written (e.g., a configuration error in manage.py), coverage combine will fail with "no data to combine." This is actually desirable (loud failure), but worth knowing it's a possible confusion point when debugging early-stage CI failures on this step.

source = ["netbox/"] is a working-directory-relative path

pyproject.toml line 30. Coverage resolves this relative to the current working directory at run time, not relative to pyproject.toml. This matches the previous --source="netbox/" CLI flag, so behavior is unchanged — but anyone running coverage from a subdirectory (e.g., netbox/) locally will silently get no source data. Not a regression, just worth noting since the config is no longer self-documenting about that constraint.

---

[jeremystretch]

Nice work!