Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Switch coverage providers? #1995

Closed
adamjstewart opened this issue Apr 14, 2024 · 2 comments
Closed

Switch coverage providers? #1995

adamjstewart opened this issue Apr 14, 2024 · 2 comments
Labels
good first issue A good issue for a new contributor to work on testing Continuous integration testing

Comments

@adamjstewart
Copy link
Collaborator

adamjstewart commented Apr 14, 2024

Summary

We should consider switching coverage providers.

Rationale

We've been proudly using codecov since the beginning of the project, but codecov has become unusable over the last year. The vast majority of tests result in 404 errors during coverage upload: codecov/codecov-action#903. The "solution" is to use our codecov secret during upload: codecov/feedback#126. However, secrets are not shared with forks, where 99% of our PRs originate from. The codecov team has not provided any recommendations for how to use codecov for open source projects, and coverage uploads now have a nearly 100% failure rate: codecov/feedback#301.

Implementation

My first thought was to replace codecov in a single PR, but I think it's actually much easier and safer to simply add additional coverage providers and test them jointly for a few weeks before making a final decision. This will prevent service disruption and allow us to explore features before making a decision.

Alternatives

There are many alternatives to codecov:

Spack used to use coveralls, but we switched to codecov because it offered GitHub integration (you could see the lines of coverage in your PR). However, codecov abandoned GitHub integration, meaning they no longer have any significant advantage over coveralls or codacy other than support for more languages (we only care about Python anyway).

Additional information

It would be interesting to get feedback from all of these providers to see what features they offer and whether or not they suffer from the same GitHub API rate limit that codecov does:

@adamjstewart adamjstewart added the testing Continuous integration testing label Apr 14, 2024
@adamjstewart adamjstewart mentioned this issue Apr 14, 2024
8 tasks
@adamjstewart
Copy link
Collaborator Author

I've removed codecov as a required status check since it almost never passes. For now, we'll have to manually verify whether or not coverage really decreases.

There is some movement upstream: codecov/feedback#301 (comment)

I think it's still worth adding coveralls and codacy to CI just to see how they compare and see if they can get us reliable coverage reports while we wait for codecov to come back online.

@adamjstewart
Copy link
Collaborator Author

Codecov seems to be reliably working again. Let's close this for now, although I'm still open to the idea of relying on multiple coverage providers for redundancy.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue A good issue for a new contributor to work on testing Continuous integration testing
Projects
None yet
Development

No branches or pull requests

1 participant