+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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev