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
