Re: [hibernate-dev] Jenkins job priorities

+1 On Wed, Jan 10, 2018 at 11:08 AM, Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > On 10 January 2018 at 10:25, Guillaume Smet <guillaume.smet(a)gmail.com&gt; wrote: >> Hi, >> >> On Wed, Jan 10, 2018 at 11:06 AM, Yoann Rodiere <yoann(a)hibernate.org&gt; 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. > > Thanks, > Sanne > >> >> -- >> Guillaume >> _______________________________________________ >> 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