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
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.
https://github.com/brettcannon/cpython-ci-test has configurations for both
CircleCI and Travis. If I'm missing something in either configuration then
please let me know (e.g. there is still a free container to use on
CircleCI). If I also missed a better CI service then also let me know (but
I don't think I have).
Otherwise please look at the output of both CI services and let it be known
which service you prefer (i.e. +1/+0/-0/-1 for both services). Ignore the
fact that the doc tests are failing as I have fixed that in Python 3.6 and
3.7 already. Consider ease of reading the output, how long it took to build
(e.g. I might turn off macOS support on Travis because they seem to have
under-provisioned those machines), etc.
Since Python 3.6.0 is due in just under a month it means we're hopefully in
the home stretch of getting things in line to do the GitHub migration by
the end of the year! This is a quick update on where things stand.
The devguide is still finished. :) That's the end of the "completed" list
In progress are reviews for the patches against bugs.python.org thanks to
Maciej and his GSoC student. Ezio is reviewing those patches and once they
go in we will then be able to test some things to make sure nothing is
going to break. I have also configured Travis and CircleCI at
https://github.com/brettcannon/cpython-ci-test to test them out (separate
email on that coming later).
I'm trying to track down the location of the code for hg.python.org/lookup
so that it can be updated appropriately. Emails for checkins and IRC
messages can be done the day of the migration (or shortly thereafter).
Updating PEP 101 or getting sys._git in can come after the migration. That
leaves updating how the buildbots get triggered and pull down code (email
out to python-buildbots on that topic).
And due to the lack of tags in the mirror we will have to recreate the repo
using Senthil's script. I don't know if it's best to simply delete the
project and recreate it or to do a force-push over the mirror.
And that's where everything stands. It all seems doable by the end of the
I have set up https://github.com/brettcannon/cpython-ci-test to help test
both Travis and CircleCI as possible CI services so that we can start the
transition at an advantage instead of breaking even in terms of feature set
compared to the current workflow. (Thanks to Alexander Belopolsky for
initially looking into this.)
If you have experience with Travis and/or CircleCI, please look at the
issues and the configuration files to help test both services at their best
and submit PRs to that repo as appropriate. What I'm looking for is not
just the best build scenario coverage (i.e. as many compilers and OSs as
possible), but also fast solutions (e.g. don't bother building the docs on
every platform/compiler combo if possible). The goal is for PRs to have
good checks to make sure they don't break anything with those checks not
taking forever so that the turn-around time on PRs can be as fast as