You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Add support for doing code coverage reporting entirely on GitHub #189
It seems not that complex to upload a coverage report from each job and then combine them in an extra job: https://hynek.me/articles/ditch-codecov-python/ I am finding codecov to be more and more annoying so it might be worth having a second option?
Reacted by Clément Robert, Nathaniel Starkman and Marten van Kerkwijk
That said, given how much my attempt at #199 broke other repos running CI in different ways, maybe it is better for astropy to also ditch the reusable workflow here for CI and only keep it for wheels. That way, we only have to worry about ditching codecov in a way that works for us.
From the coverage.py docs I just found this: https://github.com/Bachmann1234/diff_cover we could use that to fail the job based on the patch coverage rather than the whole project.
made it even better by having it comment the report on the PR and update that comment with every commit. However, it requires using pull_request_target, so the workflow has to already be on main
Activity
mhvk commentedon May 29, 2024
Yes, please!!!
Cadair commentedon Jun 3, 2024
It's unlikely I am getting to this anytime soon if anyone else wants to take a run at it.
pllim commentedon Jun 8, 2024
Looks like pydata-sphinx-theme did the hard work here (uses https://github.com/py-cov-action/python-coverage-comment-action):
Though, @weaverba137 also said Coveralls still work (at least for DESI), if that is preferable.
I don't quite remember now why we switched from Coveralls to Codecov in the first place. (Something was broken?)
pllim commentedon Jun 8, 2024
That said, given how much my attempt at #199 broke other repos running CI in different ways, maybe it is better for
astropyto also ditch the reusable workflow here for CI and only keep it for wheels. That way, we only have to worry about ditching codecov in a way that works for us.astrofrog commentedon Jun 8, 2024
Why don't we just try and figure it out in the reusable workflows then we would get it to work in all coordinated packages etc too for free?
pllim commentedon Jun 10, 2024
It would be a breaking change. I see very specific codecov settings.
Cadair commentedon Jun 10, 2024
There's a generic
coveragekey: https://github-actions-workflows.openastronomy.org/en/latest/tox.html#coverage so we can add acoverage: githubwhich people can opt-in to. I don't think this has to be a breaking change.Cadair commentedon Jun 10, 2024
From the coverage.py docs I just found this: https://github.com/Bachmann1234/diff_cover we could use that to fail the job based on the patch coverage rather than the whole project.
zacharyburnett commentedon Jun 25, 2024
here's a usage of
diff-cover(assuming the coverage files are uploaded as artifacts earlier in the run)https://github.com/spacetelescope/stpipe/pull/160/files#r1653419802
zacharyburnett commentedon Jun 26, 2024
made it even better by having it comment the report on the PR and update that comment with every commit. However, it requires using
pull_request_target, so the workflow has to already be onmainpllim commentedon Jun 26, 2024
Re: pull_request_target -- I can always test on my astropy fork instead of astropy proper in that case.
tl;dr -- Does it report patch coverage, or just project?
pllim commentedon Jun 26, 2024
Actually, I have concern... Please see https://github.com/astropy/astropy/pull/16619/files#r1655466104
pllim commentedon Feb 25, 2026
Oooo is there an example of #207 in action?