On 5 January 2018 at 15:04, Steve Ebersole <st...@hibernate.org> wrote: > TBH, I'm ok with just dropping the TODO collection as a part of the Jenkins > jobs.
Even better, that will bring down the times from 15m to 12m :) Doing that now. > > On Fri, Jan 5, 2018 at 8:56 AM Sanne Grinovero <sa...@hibernate.org> wrote: >> >> On 5 January 2018 at 14:07, Steve Ebersole <st...@hibernate.org> wrote: >> > I have no idea what GitBlamer is. Never heard of it >> >> I figured it out; it's implicitly (by default) invoked by the job >> tasks of finding "TODO"'s and similar markers in the project, >> to add "blame" information to the final report. >> >> So for each and every warning the report would produce, it will dig >> into the git history of the project to figure out who introduced the >> marker. I disabled this "blame" process, I hope that's allright - it >> worked fine now, producing a full build in 15 minutes: >> >> - http://ci.hibernate.org/job/hibernate-orm-master-h2-main/955/console >> >> Since we didn't see this problem before I guess it's a new "feature" >> caused by me by upgrading the plugins. >> I disabled that "feature" globally as I don't think it's reasonable >> for any of our projects.. >> >> Thanks, >> Sanne >> >> > >> > >> > On Fri, Jan 5, 2018, 7:38 AM Sanne Grinovero <sa...@hibernate.org> >> > wrote: >> >> >> >> On 5 January 2018 at 13:12, Sanne Grinovero <sa...@hibernate.org> >> >> wrote: >> >> > On 5 January 2018 at 12:28, Steve Ebersole <st...@hibernate.org> >> >> > wrote: >> >> >> FWIW... I do not know the rules about how these slaves spin up, but >> >> >> in >> >> >> the >> >> >> 10+ minutes since I kicked off that job it is still waiting in >> >> >> queue. >> >> > >> >> > When there are no slaves it might take some extra minutes; on top of >> >> > that I was manually killing some leftover machines from yesterday's >> >> > night experiments, so maybe I bothered it in some way. >> >> > >> >> > Let's keep an eye on it, if it happens regularly we'll see what can >> >> > be >> >> > done. I'll likely want to keep a slave "always on".. >> >> > >> >> >> And there is actually a job (Debezium Deploy Snapshots) in front of >> >> >> it >> >> >> that has >> >> >> been waiting over 3.5 hours >> >> > >> >> > That was my fault, thanks for spotting it! (the job was >> >> > misconfigured, >> >> > fixed now). >> >> > >> >> >> On Fri, Jan 5, 2018 at 6:20 AM Steve Ebersole <st...@hibernate.org> >> >> >> wrote: >> >> >>> >> >> >>> I went to manually kick off the main ORM job, but saw that you >> >> >>> already >> >> >>> had >> >> >>> - however it had failed with GC/memory problems[1]. I kicked off a >> >> >>> new >> >> >>> run... >> >> > >> >> > These boxes have 4 core and 8GB RAM heach. We can probably use larger >> >> > heaps: I've reconfigured the gradle and Maven environment options to >> >> > allow 4GB of heap, and kicked a new ORM build. >> >> >> >> The Gradle build completed fine now, in just 12 minutes. >> >> However then the job gets stuck on: >> >> >> >> <Git Blamer> Using GitBlamer to create author and commit >> >> information for all warnings. >> >> >> >> It's been busy 15 minutes already at this point - so taking longer >> >> than the build and tests - and still going.. >> >> What is it? is it worth it? something wrong with it? >> >> >> >> - http://ci.hibernate.org/job/hibernate-orm-master-h2-main/953/console >> >> >> >> Thanks, >> >> Sanne _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
