On Thu, Feb 5, 2009 at 6:47 PM, Tim Ellison <[email protected]> wrote:
> Egor Pasko wrote: > > On the 0x54C day of Apache Harmony Tim Ellison wrote: > >> Egor Pasko wrote: > >>> On the 0x547 day of Apache Harmony Tim Ellison wrote: > >>>> I now have an account [1] on the ASF Hudson machine, so can host some > >>>> more visible build and test projects there. > >>>> > >>>> To get things started, I created a simple build job which will send > mail > >>>> to the alerts@ list if the compile fails. > >>>> > >>>> http://hudson.zones.apache.org/hudson/view/Harmony/ > >>> Awesome! Now I do not have to ask people out there to check my patches > >>> on x86_64 :) Thanks, Tim! > >>> > >>>> Next step is to pass the results of that build into a short integrity > >>>> testing cycle. > >>> I am seeing results of short integrity testing runs on Hudson. Does it > >>> mean this is done already? > >> It's still work in progress, but yes, just about done. > >> > >> I enhanced the 'build' job to include a very basic test (at this point > >> it just runs the pack200 Junit tests. This is to ensure that not only > >> the build completes successfully, but that it also runs a very simple > >> set of 'sniff' tests. > >> > >> I'm open to suggestions about what the sniff tests should be, but they > >> should take next to no time at all to run after the build completes. > > > > 'sniff' testing in basic build is a good idea. And I guess pack200 > > unit tests should be just the right amount to be next to no time. > > > >> Once the short integration testing is working I'll redirect failures to > >> the alerts list too, and schedule that to run frequently (being mindful > >> that we are on a shared machine resource). Then I'll move on to running > >> longer tests, etc. etc. > > > > cool, ehwa running is already very useful > > I'm still struggling with the BTI, trying to adapt it to do the right > thing. Not sure if I can help here. I myself setup BTI in my servers according to the readme files before. As to the issue of -Duse.libstdc++6=true, I also locally modify the adaptor to include the option thus to continue testing. > > > >>> Is there a plan to set up an x86 build on Hudson? How much more > >>> platforms/configurations is reasonable to run without making others > >>> feel that we are wasting machine resources? > >> AFAIK there is not a wide range of machine architectures available as > >> Hudson build machines. I will discuss with the infra team what we can > >> get available. > > > > we could build and run a 32 bit binary on an x86_64 machine, but that > > is likely a pain to set up our BTI for this. Is there support for > > virtual machines? :) > > I believe they are hosting them as virtual hosts already, so it is a > case of asking for other architectures to be made available. I wanted > to get a basic build / test going on one machine first. > > >> I think we can use more resources on the current machine if you can > >> think of other configurations you want to run. > > > > It might be helpful to build release configuration so that users are > > able to pick new binary snapshots anytime. (this would sound very > > cool: "We don't have fresh 32 bit binaries, try our x86_64 builds). > > The builds are in release mode by default anyway. > The latest good build is available at... > > http://hudson.zones.apache.org/hudson/view/Harmony/job/Harmony-1.5-head-linux-x86_64/lastSuccessfulBuild/ > > > Since DRLVM is not in a very active development we may save resources > > and take DRLVM binary from the latest binary release. > > Rebuilding it is no problem. > > > I'll be glad to also find 2 runtime configurations in testing (client > > and server). But .. not very critical. > > I'll bear it in mind once I am running tests. > > Regards, > Tim >
