Accept a PR but only push it once tests pass?
Hi,
Would it be possible to modify the workflow of GitHub pull requests to allow to click on Merge, but only merge a PR once tests complete and only if tests pass?
If some tests start to become too annoying for the pre-commit CI, we can try to fix them, or even disable them in the CI to only rely on post-commit buildbots.
Victor
On Tue, Feb 14, 2017 at 9:10 AM, Victor Stinner victor.stinner@gmail.com wrote:
Would it be possible to modify the workflow of GitHub pull requests to allow to click on Merge, but only merge a PR once tests complete and only if tests pass?
Yes, that is possible.
I am +1 in doing that. I hope others are on the same page. If in agreement, I will enable that in github.
It's called "Require status checks to pass before merging" and we can enable travis-ci to go green before allowing to merge.
Thanks, Senthil
On Tue, 14 Feb 2017 at 09:19 Senthil Kumaran senthil@uthcode.com wrote:
On Tue, Feb 14, 2017 at 9:10 AM, Victor Stinner victor.stinner@gmail.com wrote:
Would it be possible to modify the workflow of GitHub pull requests to allow to click on Merge, but only merge a PR once tests complete and only if tests pass?
Yes, that is possible.
I am +1 in doing that. I hope others are on the same page. If in agreement, I will enable that in github.
It's called "Require status checks to pass before merging" and we can enable travis-ci to go green before allowing to merge.
The reason I didn't turn that on to begin with was I wanted to wait until we had proven to ourselves that our test suite was stable enough to not block PRs on a regular basis due to some flaky test. If people feel the tests are passing consistently when they should then I'm all for flipping on this protection.
2017-02-14 18:38 GMT+01:00 Brett Cannon brett@python.org:
The reason I didn't turn that on to begin with was I wanted to wait until we had proven to ourselves that our test suite was stable enough to not block PRs on a regular basis due to some flaky test. If people feel the tests are passing consistently when they should then I'm all for flipping on this protection.
Oh ok, I see. Let's say that we wait one month to see how things are going before changing the process ;-)
Hopefully the Travis CI jobs are currently quite fast: less than 10 minutes, whereas many buildbots take longer than 1 hour! (up to 5 hours in the worst cases)
Victor
On Tue, Feb 14, 2017 at 9:56 AM, Victor Stinner victor.stinner@gmail.com wrote:
Oh ok, I see. Let's say that we wait one month to see how things are going before changing the process ;-)
I'd say we do it and see if it is worth keep it that way.
The PR tests are passing and we have an incentive to maintain that.
The only tests which have a Red mark (failing ci) are not those whose branches are not rebased against the HEAD of master. So, if we make it a requirement, authors will have to rebase their changes on top origin/master HEAD, and will get accurate test information for their PR.
-- Senthil
participants (3)
-
Brett Cannon -
Senthil Kumaran -
Victor Stinner