Coverage reporting through Travis?
Now that we have settled on Travis, the next question is whether we can calculate coverage results fast enough to not have the process killed, as well as who to use for the coverage report. For the measurement run, we can add a separate run to the build matrix so as to not accidentally mix any weird interaction with coverage.py and Python itself. It also allows us to flag the coverage reporting as acceptable to fail and thus not get a false-negative on the CI run. I don't know if procedural or concurrent coverage measurement http://coverage.readthedocs.io/en/coverage-4.2/subprocess.html#configuring-p... will work out best, so both will need to be tested. I also don't know if branch coverage will be too slow for Travis' time limit. If anyone thinks this logic is flawed or missing something then please let me know. As for coverage-reporting services, I know of https://codecov.io/ and https://coveralls.io/. If people have any other recommendations I'm open to hearing about them. I will continue to use https://github.com/brettcannon/cpython-ci-test to experiment with code coverage services.
Hi!
On Mon, Nov 21, 2016 at 09:22:36PM +0000, Brett Cannon
As for coverage-reporting services, I know of https://codecov.io/ and https://coveralls.io/. If people have any other recommendations I'm open to hearing about them.
The only minor difference between them that I know of is: if one updates a pull request using force-push codecov updates its comment and coveralls adds a new comment every time. See for example this PR: https://github.com/andialbrecht/sqlparse/pull/279 - I've updated it 5 times; there is one updated comment from codecov and 5 comments from coveralls. If you prefer one way or the other - you know what to choose. Oleg. -- Oleg Broytman http://phdru.name/ phd@phdru.name Programmers don't die, they just GOSUB without RETURN.
participants (2)
-
Brett Cannon
-
Oleg Broytman