Fix(coverage): Use package name in coverage source list#285
Open
ModeSevenIndustrialSolutions wants to merge 1 commit into
Open
Fix(coverage): Use package name in coverage source list#285ModeSevenIndustrialSolutions wants to merge 1 commit into
ModeSevenIndustrialSolutions wants to merge 1 commit into
Conversation
There was a problem hiding this comment.
Pull request overview
This PR fixes a latent coverage configuration issue in pyproject.toml by switching Coverage.py’s [tool.coverage.run].source from a filesystem path filter ("src") to the importable package name ("dependamerge"), ensuring coverage collection works even with non-editable installs (e.g., in CI).
Changes:
- Update
[tool.coverage.run] sourcefrom["src"]to["dependamerge"]to make coverage instrumentation resilient to install location.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
9e7c540 to
c45f031
Compare
c45f031 to
5e52739
Compare
5e52739 to
bd065dd
Compare
This was referenced May 12, 2026
source = ['src'] is a filesystem path; coverage.py treats entries containing a path separator as path filters. Under lfreleng-actions/python-test-action v1.1.x, which installs the package non-editably into .venv/lib/pythonX.Y/site-packages, that filter never matches the installed location and coverage reports 0% with a 'No data was collected' warning. Use the import name 'dependamerge' instead. coverage.py instruments the package wherever it is imported from. This is currently masked because addopts includes '--cov=dependamerge', which overrides the path-based source list. The fix removes the latent failure mode so the project remains correctly measured if addopts is changed or the action's flag handling evolves. [tool.coverage.paths] is left in place: it does not affect measurement (this bug) but does help when combining coverage data files from multiple environments during reporting. Co-authored-by: Claude <claude@anthropic.com> Signed-off-by: Matthew Watkins <mwatkins@linuxfoundation.org>
61be861 to
3b477bb
Compare
3b477bb to
636b08b
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Single-file, single-line fix to
pyproject.tomlcorrecting alatent coverage configuration bug.
[tool.coverage.run] source = ["src"]is a filesystem path.coverage.py treats entries containing a path separator (or
matching a directory on disk) as path filters. Under
lfreleng-actions/python-test-actionv1.1.x — which installs the package non-editably into
.venv/lib/pythonX.Y/site-packages/— that filter never matchesthe installed location, so coverage reports 0% with a
No data was collectedwarning.The fix is to use the import name (
dependamerge) instead.coverage.py instruments the package wherever it is imported from,
regardless of install location.
Why this is preventive
The bug is currently masked because
addoptsincludes--cov=dependamerge, which overrides the path-basedsourcelist at the CLI. Removing the latent failure mode means the
project remains correctly measured if
addoptschanges or ifthe action's flag handling evolves.
[tool.coverage.paths]is left in place: it does not affectmeasurement, but does help when combining coverage data files
from multiple environments during reporting.
Related fixes
The same root cause has been addressed in sibling projects:
Change
Note
This PR previously also carried the "repo-scoped merge output
reporting" fixes; those have been consolidated into #277 so the
two changes can be reviewed together as a single coherent merge-
path improvement. This PR is now scoped to the trivial
single-file coverage fix.