Starting a new slave only takes 3 minutes, but I believe it has to be a "manual start" from its admin dashboard as Jenkins's scaling plugin is limited.
Fixing the Jenkins triggers would be my preference. Alternatively: - we could look at pipelines - run all jobs within Docker -> improved isolation would allow us to run N builds per machine - combine these: run it all on Openshift On 30 April 2018 at 17:09, Guillaume Smet <guillaume.s...@gmail.com> wrote: > Hi, > > So, as expected, I'm not very happy with the new CI setup when doing > releases. > > The issue is that each commit to ORM triggers at least 5 jobs (5.0, 5.1, > 5,2, master-h2, master-check) which takes all the slave bandwidth we have. > > Note that I'm talking of ORM because it's where the issue is the most > prominent but I'm pretty sure I would have the same issue with HV, > considering we now have quite a few maintenance branches, except that the > HV builds are faster. > > So I would say: > - either we fix the issue we have with all the branches being tested for > each commit that we discussed numerous times > - or we need a mechanism to start specific slaves for releases - but I'm > not sure it's fast enough tbh > > Because it's really annoying. Especially when you have to run your release > job 3 times in a row due to SF.net issues... > > Releasing is already a tedious process, let's not make it even more tedious. > > (yeah I know it's not the first time I complain about it but it's really > worse than it was before) > > -- > Guillaume > _______________________________________________ > 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
