It's not about Jenkins letting two build plans to run from the same directory, but rather where you set tempDir to. If both are set to say java.io.tmpdir, then you get a collision. I configured both builds to set a unique tempDir, and that's working fine so far.
Was just thinking that it'll be easier if we appended the PID to the dir. It just makes it even more unique, though I understand your point about losing the ability to debug when you have too many J0-<PIDs>. BTW, doesn't the runner mkdirs() J0,J1 etc.? After I set the builds to tempDir/job1 and tempDir/job2, I hit FNFE, until I manually created these dirs. Shai On Sun, Dec 23, 2012 at 10:49 AM, Dawid Weiss <dawid.we...@cs.put.poznan.pl>wrote: > I would say separating builds should be the duty of a build container. > If Jenkins somehow allows two build plans to run from the same > directory then I think it's either a bug or a risky feature. > > This said, there are also downsides of appending anything that changes > (per-run) to build directories -- you won't be able to tell where your > JVMs (and their output files) are created, if stuff is left behind > you'll have an incremental mess from which it'll be hard to determine > what's recent, what's stale, what failed, etc. > > I know this for a fact because I initially created current working > directories in a temporary folder (at random). It was hell. > > Dawid > > On Sun, Dec 23, 2012 at 8:43 AM, Shai Erera <ser...@gmail.com> wrote: > > Hi > > > > Today each JVM receives its own work.dir, e.g. J0, J1 and so forth. I > think > > I've hit on my Jenkins an error that was caused due to overlapping > builds, > > one deleted the work.dir of the other. > > > > So maybe we can do a best effort to detect the PID and if success, > append it > > to work.dir, e.g. J0_9324? If the JVM ManagementBean is able to return a > > parseable PID, then we use it, otherwise we stick w/ J0. > > > > Is it possible? > > > > In the meanwhile, I've configured my Jenkins to not run overlapping > builds. > > > > Shai > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
