Is this to do with Hudson handing out build jobs to "slaves"? There's a checkbox on the project config page which you can select to restrict which slaves Hudson uses. Does that not help any? I can't remember if that's standard behaviour or a plugin. Or maybe I've got the wrong end of this stick?
On Mon, Oct 25, 2010 at 5:03 PM, Patricia Shanahan <[email protected]> wrote: > Thanks for the reminder. I'd forgotten about the random element in how > Hudson runs the tests. > > I am strongly in favor of controlling which system we run on. For one thing, > I think a release candidate should be run in as many different environments > as possible, and not being able to control which OS Hudson uses limits that. > > Since you obviously remember this problem, but voted for javaspace as my > next bug hunt target, I assume you consider this lower priority the > javaspace failures. Of course, that does not mean it has no priority - maybe > I'll get to this next after javaspace. > > Patricia > > > > > > Jonathan Costers wrote: >> >> This error has happened since day one, when Hudson builds and tests on the >> solaris1 instance. >> It is specific to Solaris, and does not happen on the ubuntu instances. >> I highlighted this happening many times before. >> You can check the build output for all solaris builds and compare to the >> ubuntu builds if you need confirmation of my statement. >> >> This error is the whole reason why I would like to setup separate builds: >> - one running only on solaris instances >> - one running only on ubuntu instances >> >> 2010/10/24 Patricia Shanahan <[email protected]> >> >>> On 10/24/2010 8:55 AM, Apache Hudson Server wrote: >>> >>>> See<https://hudson.apache.org/hudson/job/River-trunk-QA/41/changes> >>>> >>>> Changes: >>>> >>>> [pats] Add comment documenting use of "+," to embed a comma in a test >>>> JVM >>>> argument. >>>> >>> The failure was: >>> >>> [java] >>> com/sun/jini/test/spec/lookupdiscovery/MulticastMonitorAllChange.td >>> [java] Test Failed: Test Failed: >>> com.sun.jini.qa.harness.TestException: >>> change failed -- waited 870 seconds (14 minutes) -- 3 change event(s) >>> expected, 0 change event(s) received >>> >>> This result is more likely to be an intermittent failure due to a >>> concurrency bug than caused by adding a comment to qaDefaults.properties. >>> I'll put a VirtualBox to work running the test repeatedly to see if it >>> will >>> fail for me, and if so whether I can make it happen more often to aid >>> debug. >>> >>> Patricia >>> >> > >
