[core-workflow] Coverage reporting through Travis?

[Brett Cannon]

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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/core-workflow/attachments/20161121/3be37e18/attachment-0001.html>