Mailman 3 November 2016 - core-workflow

Choosing a code coverage reporter
by Brett Cannon 03 Dec '16

03 Dec '16

I have both Codecov and Coveralls up and running. If you have an opinion/preference, please vote at https://github.com/brettcannon/cpython-ci-test/issues/27 using the reactions on the appropriate comment (.e.g +1/-1 reaction for Codecov and/or Coveralls). Links to the code coverage results are in the issue. If people want to see how they interact with PRs, feel free to look at https://github.com/brettcannon/cpython-ci-test/pull/32 (once the CI run is finished).

2 3

Coverage reporting through Travis?
by Brett Cannon 21 Nov '16

21 Nov '16

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-…> 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.

2 1

CircleCI or Travis?
by Brett Cannon 21 Nov '16

21 Nov '16

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.

7 9

GitHub migration status as of 2016-11-18
by Brett Cannon 19 Nov '16

19 Nov '16

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 for now. 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 year!

2 2

Getting help w/ testing Travis and CircleCI
by Brett Cannon 05 Nov '16

05 Nov '16

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 possible.

2 1