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-python-for-sub-process-coverage> 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.
_______________________________________________ core-workflow mailing list core-workflow@python.org https://mail.python.org/mailman/listinfo/core-workflow This list is governed by the PSF Code of Conduct: https://www.python.org/psf/codeofconduct
