That's it, thanks! On Fri, Jun 24, 2016 at 11:13 AM Sanne Grinovero <sa...@hibernate.org> wrote:
> On 24 June 2016 at 16:40, Steve Ebersole <st...@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 <gbad...@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 <st...@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 <sa...@hibernate.org> > >>> wrote: > >>> > >>> > On 18 June 2016 at 18:50, Chris Cranford <cranc...@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@lists.jboss.org > >>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > > > >>> > > _______________________________________________ > >>> > > hibernate-dev mailing list > >>> > > hibernate-dev@lists.jboss.org > >>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > _______________________________________________ > >>> > hibernate-dev mailing list > >>> > hibernate-dev@lists.jboss.org > >>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > >>> > > >>> _______________________________________________ > >>> hibernate-dev mailing list > >>> hibernate-dev@lists.jboss.org > >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > >> > >> > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
