I'll add another way to exclude other jobs: make a slave with only one executor and tie the jobs to restrict to the slave. Only one at a time will run.
-- Sami Jan Seidel <wakkal...@gmail.com> kirjoitti 28.6.2012 kello 13.41: > Hi folks, > > I am trying to parallelize some of our builds to speed things up. > This particular build is quite special as it also interacts with databases. > Multiple write access on a database will wreck the content, so this must be > avoided by all means. It takes us in worst cast out of business for 2 weeks > and creates loads of work and stress. > > Don't ask me why the DB design is as it is, that's pretty complicated, > insane, sooo wrong and not worth discussing in order to fix that issue and > let the build jobs just do what they are meant to do. > Have been there, didn't like it, went away! > > The initial build job is a dispatcher that decides which job to run. So far > quite easy but it also checks for 2 conditions which requires to almost > identical jobs asides of one of the repositories location. > So the jobs access mostly the same ressources including the database which > must not be simultaneously! So they are a kind of "siblings" > The default is set that inhibits to spawn duplicate jobs but with this second > condition is it changing a bit. The second condition requires to block a job > if a duplicate or the sibling is running > > This brings me to a dumb situation. Either I find a way to: > refer to related AND non-related jobs which may block a build > block on top-level (the dispatcher). This works but scraps all my efforts to > get jobs not sharing same ressources to run in parallel > do not block jobs and hope that the developers don't botch it and wreck a > database *yuk* > Do you know a solution to block a job if a clone or a sibling already is > running? > > > > > > Cheers > > Jan
