Replies: 3 comments
-
|
The greatest advantage would be to set coverage standards, either overall for the project, or for patches. See https://docs.codecov.com/v4.6/docs/github-5b-setting-coverage-standards-with-flags |
Beta Was this translation helpful? Give feedback.
-
|
Most of my experience with Codecov was from several years ago, so I have no idea what (if anything) has changed during that time period. With that caveat aside… I don't recall having great experiences with Codecov, which is why Rémy and I decided to handle this topic in a different manner for Kagi, a multi-factor authentication system for Django. We decided to aim for 100% test coverage from the start, adding command-line flags to Pytest that cause test failure if coverage drops below 100%. Regardless of whether we sought 100% test coverage for Pelican, one could replace the relevant For what it's worth, my friend Hynek also ran into issues with Codecov and came up with a solution that doesn’t rely on third-party services, as he documented in a detailed post called How to Ditch Codecov for Python Projects that presumably describes how he implemented that solution for Just my two cents. I'm not totally opposed to Codecov, but it's probably clear by now that I do like the idea of achieving a similar result without relying on a third-party service. |
Beta Was this translation helpful? Give feedback.
-
|
I also like the thought of no third-party service, as long as it is easy to implement, enforce, and see. I'll read. |
Beta Was this translation helpful? Give feedback.
-
How do people feel about annotating github pull requests with code coverage? See https://docs.codecov.com/v4.6/docs/github-2-getting-a-codecov-account-and-uploading-coverage#github-actions.
We'd have to authorize codecov as a third-party application in github. See https://docs.codecov.com/v4.6/docs/github-2-getting-a-codecov-account-and-uploading-coverage#create-a-codecov-account.
Beta Was this translation helpful? Give feedback.
All reactions