The way the cycling through the FP/AIR version combinations works needs a continual loop. If we set it up to be only triggered by a git change, that means that that change is tested only against one possible combination right away, and will only be fully verified after three more commits.
I'm going to try Om's suggestion and see how the queue develops, if that doesn't work as intended - e.g. it keeps filling the queue with builds - I will revert to the current setup and see if I can prevent the torrent of emails in case of failure. EdB On Sat, Sep 28, 2013 at 9:12 AM, Justin Mclean <jus...@classsoftware.com> wrote: > Or only build on a git change? > On 28/09/2013 4:42 PM, "OmPrakash Muppirala" <bigosma...@gmail.com> wrote: > >> Can you just set it up with every hour on each build? We have only one >> slave so the others will be queued. They will have to run sequentially >> then. >> >> Thanks, >> Om >> >> >> On Fri, Sep 27, 2013 at 11:26 PM, Erik de Bruin <e...@ixsoftware.nl> >> wrote: >> >> > Yeah, sorry about that. >> > >> > It's set up that way because the time it takes to run any of these >> > suites varies significantly. I want them to run as often as possible, >> > so as soon as one of them is done, it launches the next... in a loop. >> > Loops are never a really good idea, especially when Java is involved >> > ;-) However, the only alternative I can think of is to have a timer >> > and a timer would have to take into account the variable run length. >> > And that would mean a lot less runs. >> > >> > Usually I reboot the whole process often enough to prevent this from >> > happening, but apparently things have been running so well the last >> > week or so that there were enough runs to cause this. I'll look into a >> > different set up, or a way to prevent the torrent of failure emails. >> > >> > EdB >> > >> > >> > >> > On Sat, Sep 28, 2013 at 7:30 AM, OmPrakash Muppirala >> > <bigosma...@gmail.com> wrote: >> > > On Fri, Sep 27, 2013 at 8:50 PM, OmPrakash Muppirala >> > > <bigosma...@gmail.com>wrote: >> > > >> > >> I will take a look at what is going on. I've disabled the builds for >> > >> now. >> > >> >> > >> Thanks, >> > >> Om >> > >> >> > >> P.S. The credentials for this VM was sent to the private list by >> Erik a >> > >> while ago. >> > >> >> > >> >> > > Looks like a build loop was created and the VM ran out of memory. I >> have >> > > restarted the box and rescheduled the builds. It should hopefully be >> > okay >> > > for now. >> > > >> > > Erik, the build dependencies look a bit like Inception. Are you sure >> the >> > > build order is correct? I will wait for you to weigh in before I go >> > change >> > > something. >> > > >> > > Thanks, >> > > Om >> > > >> > > >> > > >> > >> >> > >> >> > >> >> > >> On Fri, Sep 27, 2013 at 4:53 PM, Justin Mclean <jmcl...@apache.org> >> > wrote: >> > >> >> > >>> Hi, >> > >>> >> > >>> Looks like it's run out of memory and is spamming the commits list >> and >> > >>> me, so I get each email twice. Any reason why I get special >> treatment? >> > >>> >> > >>> From: flex.muste...@gmail.com >> > >>> To: comm...@flex.apache.org, jmcl...@apache.org >> > >>> >> > >>> Any chance someone could wind back what it does when there's a >> failure, >> > >>> rather than trying to rebuild every 5 or 10 minutes when there is >> one? >> > >>> Don't believe I have access. >> > >>> >> > >>> Once per hour when there a git change and once/day should be good >> > enough >> > >>> and if there's a failure don;t try and rebuild just wait for the next >> > >>> change or day to pass. >> > >>> >> > >>> Also changing the URL in the email to be a real URL might be a good >> > idea >> > >>> - if that's easily possible. >> > >>> http://localhost:8080/job/flex-sdk_mustella/381/ >> > >>> >> > >>> Thanks, >> > >>> Justin >> > >> >> > >> >> > >> >> > >> > >> > >> > -- >> > Ix Multimedia Software >> > >> > Jan Luykenstraat 27 >> > 3521 VB Utrecht >> > >> > T. 06-51952295 >> > I. www.ixsoftware.nl >> > >> -- Ix Multimedia Software Jan Luykenstraat 27 3521 VB Utrecht T. 06-51952295 I. www.ixsoftware.nl
