+1 I think (1) and (2) on each push still makes sense with (3) being nightly.
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
