Re: [hibernate-dev] Jenkins job priorities
On 10 January 2018 at 10:25, Guillaume Smet <guillaume.smet(a)gmail.com> wrote:
Hi,
On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere <yoann(a)hibernate.org> wrote:
>
> I hope we will be able to use this priority feature instead of the Heavy
> Job plugin (which allows to assign weights to jobs), and avoid concurrent
> builds completely. With the current setup, someone releasing his/her
> project will only have to wait for the currently executing build to finish,
> and will get the highest priority on the release builds. Maybe this is
> enough? If you disagree, please raise your concerns now: I will disable the
> Heavy Job plugin soon and set each slave to only offer one execution slot.
Thanks Yoann! that sounds great.
>
I'm not really convinced by this solution. Some jobs still take quite a lot
of time and having to wait 20 minutes for each job I would trigger is a bit
annoying.
If it was for only one job, it would be acceptable, but let's take the
worst case of a coordinated HV release :
- TCK release
- API release
- HV release
- website
- blog
I won't have to wait for each of them as some of them will be grouped by
the prioritization but I'm pretty sure I will have to wait for several of
them.
So, I'm +1 on having this plugin as it seems to be helpful on its own but
I'm -1 on considering it is a solution to the "let's roll a release"
thing.
Some of our test suites used to take 2 hours to run (even 5 days some
years ago); now you say waiting 20 minutes is not good enough? You'll
have to optimise our code better :P
It's very easy to spin up extra nodes; my recommendation is that when
you know you're about to release [for example approximately one hour
in advance while you might be double-checking JIRA state and such
things] hit that manual scale-up button and have CI "warmed up" with
one or two extra nodes.
By the time you need to trigger the release job you'll have the build
queue flushed, the priority plugin helping you out, and still
additional extra slaves running to run it all in parallel.
And of course for many releases we don't care for an extra 30 minutes
so you're free to skip this all if it's not important; incidentally
for "work in progress" milestones like the module packs which we
recently re-released several times while polishing up the PR I've been
releasing from my local machine; it's good to have CI automate things
but I don't think we should get in a position to require 100%
availability from CI: practice releases locally sometimes.
If we really wanted to invest more in it (both time and budget),
there's the option of spinning up new containers for each job as soon
as you need one but I feel like we've spent too much time on CI
already; such technology is maturing so my take is let it mature a bit
more, and in 6 months we'll do another step of improvement; jumping on
those things makes us otherwise the beta testers and steals critical
time from our own projects.
Let's not forget that many Apache projects take a week or two to
perform a release, we all know of other projects needing months, so by
the law of diminishing returns I don't think we should invest much
more of out time to shave on the 10 minutes.. just spin up some extra
nodes :)
Thanks,
Sanne
--
Guillaume
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev