On 12/19/2011 4:05 AM, Martin Nowak wrote: > On Sat, 17 Dec 2011 20:54:24 +0100, Brad Roberts <bra...@puremagic.com> wrote: > >> On 12/17/2011 4:56 AM, Robert Clipsham wrote: >>> On 17/12/2011 06:40, Brad Roberts wrote: >>>> On 12/16/2011 1:29 PM, Brad Anderson wrote: >>>>> On Thu, Dec 15, 2011 at 6:43 PM, Brad >>>>> Roberts<bra...@puremagic.com<mailto:bra...@puremagic.com>> wrote: >>>>> >>>>> >>>>> Left to do: >>>>> >>>>> 1) deploy changes to the tester hosts (it's on 2 already) >>>> >>>> done >>>> >>>>> 2) finish the ui >>>> >>>> very ugly but minimally functional: >>>> http://d.puremagic.com/test-results/pulls.ghtml >>>> >>>>> 3) trigger pull rebuilds when trunk is updated >>>> >>>> partly implemented, but not being done yet >>> >>> Idea: I noticed most pull requests were failing when I looked at it, due to >>> the main build failing - that's a lot of >>> wasted computing time. Perhaps it would be a good idea to refuse to test >>> pulls if dmd HEAD isn't compiling? This would >>> be problematic for the 1/100 pull requests designed to fix this, but would >>> save a lot of testing. >>> >>> An alternative method could be to test all of them, but if the pull request >>> previously passed, then dmd HEAD broke, then >>> the pull broke, stop testing until dmd HEAD is fixed. >>> >> >> Yeah. I know I need to do something in that space and just haven't yet. >> This whole thing is only a few evenings old >> and is just now starting to really work. I'm still focused on making sure >> it's grossly functional enough to be useful. >> Optimizations and polish will wait a little longer. >> >> Thanks, >> Brad > > Another optimization idea. Put pull request that fail to merge on an inactive > list, send a comment to github and wait until the submitter does something > about them. > > martin
Way ahead of you, but low priority on it from a throughput standpoint. Those take almost no time to process. The benefit there is in getting the notification back to the pull submitter. But that's true for all failures. :) The biggest win I can think of right now is what I'll work on next: if one platform has failed the build, skip it unless there's nothing else to do. With that, only one build is wasted, and only on the platform that's making the fastest progress anyway. Later, Brad
