[hibernate-dev] New CI slaves now available!
Sanne Grinovero
sanne at hibernate.org
Fri Jan 5 10:25:49 EST 2018
On 5 January 2018 at 15:04, Steve Ebersole <steve at 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 <sanne at hibernate.org> wrote:
>>
>> On 5 January 2018 at 14:07, Steve Ebersole <steve at 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 at hibernate.org>
>> > wrote:
>> >>
>> >> On 5 January 2018 at 13:12, Sanne Grinovero <sanne at hibernate.org>
>> >> wrote:
>> >> > On 5 January 2018 at 12:28, Steve Ebersole <steve at 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 at 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
More information about the hibernate-dev
mailing list