11:33 a.m.
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?
12:50 p.m.
+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
12:55 p.m.
+1 too.
On Sat, Jun 18, 2016 at 8:50 PM, Chris Cranford <crancran(a)gmail.com> wrote:
+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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:58 p.m.
On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:20 p.m.
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(a)hibernate.org>
wrote:
On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:11 a.m.
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(a)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(a)hibernate.org>
wrote:
> On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
10:40 a.m.
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 :)
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?
On Fri, Jun 24, 2016 at 1:11 AM Gail Badner <gbadner(a)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(a)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(a)hibernate.org>
> wrote:
>
> > On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > > _______________________________________________
> > > hibernate-dev mailing list
> > > hibernate-dev(a)lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
11:13 a.m.
On 24 June 2016 at 16:40, Steve Ebersole <steve(a)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(a)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(a)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(a)hibernate.org>
>> wrote:
>>
>> > On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > >
>> > > _______________________________________________
>> > > hibernate-dev mailing list
>> > > hibernate-dev(a)lists.jboss.org
>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> > _______________________________________________
>> > hibernate-dev mailing list
>> > hibernate-dev(a)lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> >
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
11:20 a.m.
That's it, thanks!
On Fri, Jun 24, 2016 at 11:13 AM Sanne Grinovero <sanne(a)hibernate.org>
wrote:
On 24 June 2016 at 16:40, Steve Ebersole <steve(a)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(a)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(a)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(a)hibernate.org>
>>> wrote:
>>>
>>> > On 18 June 2016 at 18:50, Chris Cranford <crancran(a)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(a)lists.jboss.org
>>> > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > >
>>> > > _______________________________________________
>>> > > hibernate-dev mailing list
>>> > > hibernate-dev(a)lists.jboss.org
>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> > _______________________________________________
>>> > hibernate-dev mailing list
>>> > hibernate-dev(a)lists.jboss.org
>>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>> >
>>> _______________________________________________
>>> hibernate-dev mailing list
>>> hibernate-dev(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>
3107
days inactive
3113
days old
8 comments
5 participants
participants (5)
-
Chris Cranford -
Gail Badner -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea