[hibernate-dev] HIbernate ORM CI builds

[Steve Ebersole]

That's it, thanks!

On Fri, Jun 24, 2016 at 11:13 AM Sanne Grinovero <sanne at hibernate.org>
wrote:

> 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
> >>
> >>
> >
>