On 5/05/10 10:46 PM, Steve Appling wrote:
I noticed the recent change to stop integration tests from running in parallel
on Windows. Is it really safe to run the integration tests in parallel on any
OS?
Safe enough. With parallel execution the dev build goes from ~16 minutes
to ~10 minutes on my machine. Plus there's some more tweaking to do
which should make this faster again. I can't go back to sequential
execution now.
The integration tests execute with their own user home directory and
working directory, so at worst we'll only corrupt the integration test dirs.
I have inadvertently run multiple gradle instances before and have on
several occasions corrupted some of the gradle caches. After this, not even
'gradle -t' would work until I did '-C rebuild'. It looked like forking
multiple gradle instances simultaneously on the same working directory would
always be a bad idea. Is this not true?
Unfortunately, I think it is true at the moment. This is something we
should fix, and running the integration tests in parallel is a simple
(if rather unpredictable) way to hunt down and fix the problems.
What I was planning to do is:
1. Start by giving each worker process it's own user home and working
directories. Then, we can switch on parallel tests on windows. There are
too many failures due to file locking for any kind of sharing on
windows. Of course, doing this hides whatever concurrency problems we have.
2. Share the user home dir across all worker processes, fixing whatever
problems arise. We might provide some way to declare that a problematic
test needs its own user home dir, until we get around to fixing the problem.
3. Same for the working dirs, where it makes sense.
Alternatively, for 2 or 3, we might keep the per-processes directories
and instead add integration tests which explicitly test that multiple
Gradle instances can share the same user and working dirs.
--
Adam Murdoch
Gradle Developer
http://www.gradle.org
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
