On Fri, 22 Jan 2016 at 14:44 Maciej Szulik <solt...@gmail.com> wrote:
> On Wed, Jan 20, 2016 at 1:51 AM, Brett Cannon <br...@python.org> wrote: > >> Bot to handle pull request merging >> '''''''''''''''''''''''''''''''''' >> As stated in the section entitled >> "`Document steps to commit a pull request`_", the desire is to >> maintain a linear history for cpython. Unfortunately, >> Github's [#github]_ web-based workflow does not support a linear >> history. Because of this, a bot should be written to substitute for >> GitHub's in-browser commit abilities. >> >> To start, the bot should accept commands to commit a pull request >> against a list of branches. This allows for committing a pull request >> that fixes a bug in multiple versions of Python. >> >> More advanced features such as a commit queue can come later. This >> would linearly apply accepted pull requests and verify that the >> commits did not interfere with each other by running the test suite >> and backing out commits if the test run failed. To help facilitate >> the speed of testing, all patches committed since the last test run >> can be applied and run in a single test run as the optimistic >> assumption is that the patches will work in tandem. >> >> Inspiration or basis of the bot could be taken from pre-existig bots >> such as Homu [#homu]_ or Zuul [#zuul]_. >> >> >> > From the experience on both OpenShift [1] and Kubernetes [2] I know > there's a need to > rerun tests quite frequently (flakes, errors, etc). One option is to close > and re-open the issue to > trigger the integrated CI services to re-run, which is cumbersome imho. > Both of the aforementioned > projects have testing bots. The one in orgin [1] is more sophisticated in > that it allows core-devs > running finer grained tests before actually merging the PR. The merge bot > runs quite bit > of the tests, but not all, possible examples include benchmarks. > Just a food for thought ;) > Thanks for the warning, Maciej. I have added a note that test re-runs should be considered in its design. Will go out with the next set of updates (hopefully tomorrow once I find out if anyone actually uses the sys._mercurial attribute).
_______________________________________________ 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
