Clinton Mead <[email protected]> writes: > Hi All > > I'm not a GHC dev so my understanding of this process is limited to this > thread but just my thoughts. > > My understanding is that we want to achieve the following two goals: > > 1. Never allow code which breaks tests to be committed to master. > 2. Ensure that master is up to date as soon as possible with recently > submitted merge requests (MR). > > The issue seems to be that the only way to ensure 1 is to use a serial > "rebase/test/make master branch" process on every MR. Which means if you > get a lot of MRs in a row you can get a queue of MRs blowing out. > > So what I propose is the following: > > 1. Keep a queue of pending MRs. > 2. When the previous test is complete, create a branch (lets call it > "pending") which is all the MRs in the queue rebased firstly on master and > then each other. Drop any MRs which fail this rebasing. > 3. Run tests against "pending" > 4. If the tests pass, "pending" becomes "master". However, if the CI for > "pending" fails, "split" pending into two (half the MRs in each, perhaps > interleaving their size also), rebase them separately on master call them > "pending1" and "pending2". If there's only one MR pending, don't "split" it > (you can't), just report the test failure to the MR owner. > 5. If either "pending1" or "pending2" passes, it becomes "master". Also, > whether either or both of "pending1" or "pending2" fails, go back to step 4 > for these. If they both pass (which probably should never happen) maybe > just merge one into master arbitrarily and put the other MRs in the pending > MR queue. > 6. Once we've merged all our MRs in to master (and perhaps through the > binary search above found the broken MR) start this process again with the > current pending MRs. > > With this process we ensure master is never broken, but we can test and > merge n MRs in log(n) time, so the MR queue will not grow arbitrarily long > if the rate of submitted MRs exceeds the rate we run CI tests on them. > > "Marge-bot" mentioned almost does what I suggest, except in the case of a > failure it runs the MRs one-by-one, instead of binary split like I suggest. > Perhaps my proposal could be best implemented as a patch to Marge-bot. > What you propose is similar to what upstream is planning [1]. While it would be nice to have a better solution until this plan comes to fruition, I'm personally a bit reluctant to put much effort into marge-bot given that it really is just a stop-gap solution.
Of course, if someone else would like to pick up this project we would be quite appreciative. Cheers, - Ben [1] https://gitlab.com/gitlab-org/gitlab-ee/issues/9186
signature.asc
Description: PGP signature
_______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
