Hi Lynn, unfortunately your qoute is not displayed in original. But hitting the translation button shows a whacko translation that in its wicked way makes sense XD I will check it out.
Tanks Jan Am Donnerstag, 28. Juni 2012 12:41:04 UTC+2 schrieb Jan Seidel: > > 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 >
