On 30.05.2018 16:36, Nick Coghlan wrote:
On 30 May 2018 at 22:30, Ivan Pozdeev via Python-Dev
<python-dev@python.org <mailto:python-dev@python.org>> wrote:
What's the big idea of separate buildbots anyway? I thought the
purpose of CI is to test everything _before_
it breaks the main codebase. Then it's the job of the contributor
rather than maintainer to fix any breakages.
So, maybe making them be driven by Github checks would be a better
time investment.
Especially since we've got VSTS checks just recently, so whoever
was doing that still knows how to interface with this Github
machinery.
If the bots cancel a previous build if a new one for the same PR
arrives, this will not lead to a significant load difference 'cuz
the number of
actively developed PRs is stable and roughly equal to the number
of merges according to the open/closed tickets dynamics.
There are a few key details here:
1. We currently need to run post-merge CI anyway, as we're not doing
linearised commits (where core devs just approve a change without
merging it, and then a gating system like Zuul ensures that the tests
are run against the latest combination of the target branch and the PR
before merging the change)
This is the only point here that looks valid (others can be refuted).
This technique limits the achievable commit rate by 1/testing_time . Our
average rate probably fits into this, though it still means delays.
2. Since the buildbots are running on donated dedicated machines
(rather than throwaway instances from a dynamic CI provider), we need
to review the code before we let it run on the contributed systems
3. The buildbot instances run *1* build at a time, which would lead to
major PR merging bottlenecks during sprints if we made them a gating
requirement
4. For the vast majority of PRs, the post-merge cross-platform testing
is a formality, since the code being modified is using lower level
cross-platform APIs elsewhere in the standard library, so if it works
on Windows, Linux, and Mac OS X, it will work everywhere Python runs
5. We generally don't *want* to burden new contributors with the task
of dealing with the less common (or harder to target) platforms
outside the big 3 - when they do break, it often takes a non-trivial
amount of platform knowledge to understand what's different about the
platform in question
Cheers,
Nick.
P.S. That said, if VSTS or Travis were to offer FreeBSD as an option
for pre-merge CI, I'd suggest we enable it, at least in an advisory
capacity - it's a better check against Linux-specific assumptions
creeping into the code base than Mac OS X, since the latter is
regularly different enough from other *nix systems that we need to
give it dedicated code paths.
--
Nick Coghlan | ncogh...@gmail.com <mailto:ncogh...@gmail.com> |
Brisbane, Australia
--
Regards,
Ivan
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
