Changing the priority is a good idea, but I think we can only skip (or de-prioritize) the master build if the last merge was an auto-merge. In that case we've essentially just run the exact same tests and can be sure they passed. After a manual merge... history tells us that's not always the case.
As for the 'passed-at-one-point' auto-merge, this is probably fine. Maybe add a limit to how old the old passing results can be? I expect this won't be such a big problem if we have the prioritization. On Sun, Nov 17, 2013 at 7:33 AM, Brad Roberts <[email protected]> wrote: > Since this was turned on, here's the pulls that have automatically > occurred. Yay! > > (2 others that I don't have the logs for, oops) > 2013-11-15T22:14:32 - calling github to merge D-Programming-Language/dmd/ > 2773 > 2013-11-15T23:36:53 - calling github to merge D-Programming-Language/dmd/ > 2770 > 2013-11-16T00:58:58 - calling github to merge D-Programming-Language/dmd/ > 2778 > 2013-11-16T02:21:52 - calling github to merge D-Programming-Language/dmd/ > 2777 > 2013-11-16T03:27:19 - calling github to merge D-Programming-Language/dmd/ > 2765 > 2013-11-16T04:46:16 - calling github to merge D-Programming-Language/dmd/ > 2779 > 2013-11-16T10:26:06 - calling github to merge D-Programming-Language/dmd/ > 2781 > 2013-11-16T12:04:29 - calling github to merge D-Programming-Language/dmd/ > 2782 > > (Where's the phobos guys.. everyone asleep still?) > > Currently the pace of merging is bottle necked by the slowest platform, > the freebsd's. The current merge criteria is that all platforms must > successfully complete a run. I'm considering changing that to something a > little less conservative, like: > > 1) 5-ish platforms must have successfully re-built against the current > master > and > 2) all platforms must have successfully built with _a_ master + the > current pull sha (ie, results for out of date commits are ignored) > > Too conservative still? Not strict enough? > > I'm also considering a build ordering change. Right now master branch > build have priority over pull builds. What do you guys think about moving > the priority to: > > 1) pending merges > 2) master branch > 3) other pulls > > This will eliminate a good number of builds that cost considerable time, > at the potential of not discovering a master break quite as quickly. > > Give me your thoughts on both changes. > > Thanks, > Brad > > _______________________________________________ > dmd-internals mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-internals >
_______________________________________________ dmd-internals mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-internals
