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 <sanne(a)hibernate.org> wrote:
>
> On 5 January 2018 at 14:07, Steve Ebersole <steve(a)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 <sanne(a)hibernate.org>
> > wrote:
> >>
> >> On 5 January 2018 at 13:12, Sanne Grinovero <sanne(a)hibernate.org>
> >> wrote:
> >> > On 5 January 2018 at 12:28, Steve Ebersole <steve(a)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
<steve(a)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