💄 Refactor the coveragepy config#3158
Conversation
6acc88f to
f883fa0
Compare
ebd6084 to
2ab8c61
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #3158 +/- ##
==========================================
- Coverage 99.62% 99.62% -0.01%
==========================================
Files 122 124 +2
Lines 18407 18381 -26
Branches 1226 1226
==========================================
- Hits 18338 18312 -26
Misses 47 47
Partials 22 22
🚀 New features to boost your workflow:
|
ad3067d to
9c872c9
Compare
CoolCat467
left a comment
There was a problem hiding this comment.
Looks good as far as I can tell, just a question about one of the config changes
| "*/src", | ||
| '*\src', |
There was a problem hiding this comment.
Why does it have both forward and backwards slash?
There was a problem hiding this comment.
also one below this also has a backwards slash
There was a problem hiding this comment.
Probably not, but I saw this practice a lot in the wild. I think modern coveragepy normalizes them but I don't want to take a chance.
There was a problem hiding this comment.
Oh, my brain parsed it as “is this necessary?” 😆 Apologies.
These are basically explicit Windows path variants.
There was a problem hiding this comment.
Ah, that makes a lot of sense.
There was a problem hiding this comment.
Having recently skimmed a bunch of codecov docs I'm pretty sure there's enough path normalization mentioned in a bunch of places that this shouldn't be needed.
|
Yeah, I only had to adapt my typical standalone config (which is easier to maintain) to the toml combo. It's all battle-tested, otherwise. |
| parallel = true | ||
| plugins = [] | ||
| relative_files = true | ||
| source = ["."] |
There was a problem hiding this comment.
Why do we need source and source_pkgs? We should only need one
There was a problem hiding this comment.
This is needed to measure coverage outside src/. One setting can only contain importable names while the other can have both importables and paths.
I had to do a lot of experiments to arrive to this config shape. Other variants may output incorrect paths into the XML report, confusing Codecov.
There was a problem hiding this comment.
(this also allows including that Cython smoke test)
There was a problem hiding this comment.
Probably that smoke test should be inside src/trio/_test
There was a problem hiding this comment.
Alternatively we could use source_pkgs = ["trio", "tests"]
There was a problem hiding this comment.
@graingert this won't work well. The combination of the two is the only config that is known not to cause problems one way or the other. Plus, it represents the shape of the project exactly — the source is the entire Git repo; the importable is whatever is in site-packages but it's also mapped back to the source for proper representation within both coveragepy and codecov.
I've seen cases where it would display test_*.py files in the root of the repository in Codecov while showing the correct paths in the coveragepy's own HTML output. And that's just one example of how things tend to break.
Can we please rely on my experience here? I happened to maintain the use of coveragepy specifically a lot in the past few years, and would like to avoid weird behaviors just because this project wants to deviate from what's gone through countless hours of debugging rather surprising corner cases.
There was a problem hiding this comment.
I added the source_pkgs feature to coveragepy for this use case
There was a problem hiding this comment.
@graingert really? I didn't know!
Still, there were cases where this specific configuration layout was the only thing that made it possible for Codecov not to break in some cases. This was in both src- and flat-layout projects (some in aio-libs, some elsewhere).
Though, I feel like it's still important to cover other things that might appear outside src/. Sometimes, these are helper scripts or something similar — by collecting such coverage, it is possible to configure Codecov-reported statuses better and be more conscious about what to take into account through exclusions.
As for adding "tests" into source_pkgs, that might work, but would not address the “covering everything” part. Plus, I'm worried about the side effects it may have on Codecov.
tests/cython/run_test_cython.py
Outdated
| @@ -0,0 +1 @@ | |||
| from . import test_cython # noqa: F401 | |||
There was a problem hiding this comment.
Possibly it makes sense to refactor test_cython to export a main function and we can then call it here
There was a problem hiding this comment.
Yeah, I thought so. But it was late and I was lazy :)
Will do!
| echo "version=$(python -V | cut -d' ' -f2 | cut -d'.' -f1,2)" | ||
| >> "${GITHUB_OUTPUT}" | ||
| - if: always() | ||
| uses: codecov/codecov-action@v5 |
There was a problem hiding this comment.
is there any problem with mixing versions? I previously hit errors I thought was caused by that.
There was a problem hiding this comment.
No, they just use different uploader and APIs. But newer versions are less prone to flaky upload crashes for some reason, as I noticed.
| "*/src", | ||
| '*\src', |
There was a problem hiding this comment.
Having recently skimmed a bunch of codecov docs I'm pretty sure there's enough path normalization mentioned in a bunch of places that this shouldn't be needed.
9c872c9 to
915b739
Compare
This comment was marked as resolved.
This comment was marked as resolved.
b9b515c to
6212cdf
Compare
graingert
left a comment
There was a problem hiding this comment.
Let's use source, or source_pkgs not both
| parallel = true | ||
| plugins = [] | ||
| relative_files = true | ||
| source = ["."] |
There was a problem hiding this comment.
Alternatively we could use source_pkgs = ["trio", "tests"]
|
Merge queue didn't work for the first time because of the flakiness of the Codecov v3 action, FTR. I've added it back. As for the test relocation and other suggestions, they are out of the scope because I don't want to fit in more requirements into this effort. Those changes can always be tried out separately and shouldn't be blocking — and it would be easier to see if they work in isolation, since this already combines a bit more changes than I'd like in one PR. |
This is a combination of changes that include: