These are two separate jobs in Jenkins, and they each have their own
build.dir (<job>/build). So I'm not worried that the builds will mess up
with each other in that way.
I am fine w/ setting tempDir to be unique per job.
It makes them, but the parent dirs must be existing, see ANT build file.
>
I don't understand. I assume the runner does something like new
File("java.io.tmpdir", "J0")? If it called mkdirs(), this should have
created all the path components.
Unless it doesn't call mkdirs().
The failure was from Jenkins, not eclipse. Do I need to <mkdir tempDir />
in my build.xml for this to not happen?
Shai
On Sun, Dec 23, 2012 at 11:46 AM, Uwe Schindler <u...@thetaphi.de> wrote:
> Hi,****
>
> ** **
>
> The problem here is not only tests. If you run 2 ANT builds in parallel
> there are more things that fail horribly (you get javac errors because of
> half-written class files, copy tasks corrumpting each other while copying
> resource, JAR tasks…). You cannot fix that unless you re-write the whole
> ANT build system. And because of that there is also no reason to change
> test environment like you propose. In my opinion, the better way would be
> to “lock” the whole checkout and prevent parallel ANT runs.****
>
> ** **
>
> > 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.****
>
> ** **
>
> It makes them, but the parent dirs must be existing, see ANT build file.
> The problem is running tests from Eclipse, which is “working somehow” but
> does not correctly separate and set up the build environments. The
> java.io.tmpdir sysprop is only set by the ANT build from the ANT script,
> the junit4 task does not modify the property at all – as Eclipse does not
> run the ant script, you have to configure java.io.tempdir yourself.****
>
> ** **
>
> Uwe****
>
> ** **
>
> P.S.: If you see Jenkins failing on those builds, it’s happening because
> Jenkins was not able to kill all processes of the previous build when you
> hit “cancel build”. In that case the following build and tests will fail
> because of the reasons I mentioned above. Otherwise Jenkins has a separate
> build dir for every build, so the above “cannot kill all processes” is a
> “bug” in Jenkins (the problem is missing process management in Java, so
> there is no portable way to kill processes from Java…).****
>
> ** **
>
> -----****
>
> Uwe Schindler****
>
> H.-H.-Meier-Allee 63, D-28213 Bremen****
>
> http://www.thetaphi.de****
>
> eMail: u...@thetaphi.de****
>
> ** **
>
> *From:* Shai Erera [mailto:ser...@gmail.com]
> *Sent:* Sunday, December 23, 2012 9:58 AM
> *To:* dev@lucene.apache.org
> *Subject:* Re: improving unique work.dir per JVM?****
>
> ** **
>
> 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****
>
> ** **
>
