[hibernate-dev] HIbernate ORM CI builds

Sanne Grinovero sanne at hibernate.org
Fri Jun 24 12:13:06 EDT 2016


On 24 June 2016 at 16:40, Steve Ebersole <steve at hibernate.org> wrote:
> I definitely want it run regularly (i.e. not "just before a release").  I'd
> be ok with it being nightly.  That's why I asked in the first place.
> Everyone who responded +1'd to it being on-each-push.  I really don't care.
> I tend to agree it should be nightly, but I only get one vote :)

For the record:
 a) you're the lead so it's nice that you ask for our opinions but
your "one vote" is deciding if you want it to.
 b) I replied "+1" on Chris's answer to you which was to do checks
only nightly, and believe Vlad also meant it that way. Sorry if this
wasn't clear.

>
> So the one bad thing about it not being per-push is that we may notify more
> than just the person that pushed the breakage.
>
> For now I went ahead and made it nightly (I think, see below) so that we can
> see how that works.
>
> To "make it nightly" I enabled 2 triggers:
> 1) after push
> 2) each night
>
> Is that inclusive or exclusive?  Really what I'd like to say is "run it
> nightly, but only if a change has been pushed" (no need to run `check` twice
> against the same inputs).  So will those triggers do that?

No, Jenkins will interpret that as a trigger on "either/or".
You need to use the option "Poll SCM", and set that to @midnight :
that means that once a night - approximately at midnight - the job
will fetch from git, and then trigger the build only if there's new
commits.

I applied this change for you on job 'hibernate-orm-master-h2-check'
.. I hope it's the right one?

Thanks,
Sanne

>
> On Fri, Jun 24, 2016 at 1:11 AM Gail Badner <gbadner at redhat.com> wrote:
>>
>> If check is so compute intensive, does it really have to be done on each
>> commit? When I've seen failures, it has been easy to figure out what is
>> wrong. Can the check job be done nightly, or on demand (e.g., before a
>> release)?
>>
>> On Sat, Jun 18, 2016 at 11:20 AM, Steve Ebersole <steve at hibernate.org>
>> wrote:
>>>
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2-main/
>>> http://ci.hibernate.org/job/hibernate-orm-master-h2-check/
>>>
>>> Initial attempt
>>>
>>> On Sat, Jun 18, 2016 at 12:58 PM Sanne Grinovero <sanne at hibernate.org>
>>> wrote:
>>>
>>> > On 18 June 2016 at 18:50, Chris Cranford <crancran at gmail.com> wrote:
>>> > > +1
>>> > >
>>> > > I think (1) and (2) on each push still makes sense with (3) being
>>> > nightly.
>>> >
>>> > +1
>>> >
>>> >  -- Sanne
>>> >
>>> > >
>>> > > Chris
>>> > >
>>> > >
>>> > > On 06/18/2016 11:33 AM, Steve Ebersole wrote:
>>> > >> We have been having a lot of timeouts on the ORM CI builds.  Mainly
>>> > this is
>>> > >> due to ancillary tasks.  Currently the ORM jobs execute:
>>> > >>
>>> > >>     1. clean
>>> > >>     2. test
>>> > >>     3. check
>>> > >>     4. :documentation:aggregateJavadocs
>>> > >>     5. publish
>>> > >>
>>> > >> A huge chunk of the time is taken up in (3) which performs (a)
>>> > checkstyle
>>> > >> and (b) findbugs.  Also, I am not sure of the benefit of building
>>> > >> aggregated javadocs for each and every CI build.  So I propose we
>>> > >> break
>>> > >> these up as follows:
>>> > >>
>>> > >>
>>> > >>     1. A check job
>>> > >>     2. A clean/test/publish job
>>> > >>     3. (?) aggregated javadocs job (?)
>>> > >>
>>> > >> This would allow us to split the cost of the Job timeout across the
>>> > jobs.
>>> > >> In fact we might even consider making some of these into nightly
>>> > >> job(s).
>>> > >> Initially in setting up this server we decided to just have
>>> > >> singular,
>>> > >> all-encompassing jobs because moving to a new dedicated set of
>>> > >> hardware
>>> > >> (dedicated to Hibernate team) was supposed to free us from jobs
>>> > >> fighting
>>> > >> for resources.  But as our jobs have grown on the dedicated hardware
>>> > >> we
>>> > are
>>> > >> seeing some of the same.  For certain we want a clean/test/publish
>>> > >> job
>>> > that
>>> > >> is run on every push.  To me the others are more flexible in terms
>>> > >> of
>>> > >> scheduling.  We could have a separate check job that is run on each
>>> > push,
>>> > >> or it could be a nightly job.  We might even decide to leave off
>>> > building
>>> > >> aggregated javadocs as an automated job/task, or we might decide to
>>> > make it
>>> > >> a nightly job as well (maybe even with full documentation builds).
>>> > >>
>>> > >> WDYT?
>>> > >> _______________________________________________
>>> > >> hibernate-dev mailing list
>>> > >> hibernate-dev at lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev at lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev at lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>


More information about the hibernate-dev mailing list