Thanks - much appreciated. A.
On Wed, Dec 30, 2015 at 1:52 PM, Gerhard Petracek <[email protected]> wrote: > @andrew: > it should be fine now. > > regards, > gerhard > > > > 2015-12-30 17:10 GMT+01:00 Gerhard Petracek <[email protected]>: > >> @andrew: >> i'll do it within the next hours. >> >> regards, >> gerhard >> >> >> >> 2015-12-30 17:05 GMT+01:00 Andrew Bayer <[email protected]>: >> >>> Please change at least the triggering ASAP, or I'll disable all the >>> DeltaSpike jobs to free up capacity for other projects until it's fixed. >>> Sorry to be harsh, but this is a colossal use of limited build resources. >>> >>> A. >>> >>> On Wed, Dec 30, 2015 at 11:02 AM, Gerhard Petracek <[email protected] >>> > wrote: >>> >>>> hi andrew, >>>> >>>> we have discussed it recently and we are going to change it soon. >>>> >>>> regards, >>>> gerhard >>>> >>>> >>>> >>>> 2015-12-30 16:57 GMT+01:00 Andrew Bayer <[email protected]>: >>>> >>>>> I discovered today while checking on load on builds.apache.org that >>>>> not >>>>> only does DeltaSpike have a huge number of jobs that poll and run >>>>> whenever >>>>> there's a change in Git - all those jobs are then kicked off *again* by >>>>> https://builds.apache.org/job/DeltaSpike%20Deploy/, which is kicked >>>>> off by >>>>> the same polling! The end result is running 50 or so jobs *twice*, >>>>> taking >>>>> half an hour or so each, for every single change that goes into >>>>> DeltaSpike. >>>>> Please, please, please fix this to only trigger your jobs once each, >>>>> not >>>>> twice, and ideally, it'd be great if you could rationalize your jobs >>>>> and >>>>> cut down the number of jobs, so as not to hog basically all the >>>>> available >>>>> slots for non-Hadoop-related jobs on builds.apache.org. Thanks. >>>>> >>>>> A. >>>>> >>>> >>>> >>> >> >
