Yes, it is relatively easy to setup a Hudson build like that, i.e. to only build on either solaris or ubuntu instances. I'm a bit busy for the moment, but as soon as I get some time I'll look into configuring it.
2010/10/25 Tom Hobbs <[email protected]> > 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 > >>> > >> > > > > >
