harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexei Fedotov <alexei.fedo...@gmail.com>
Subject Re: [build] Hudson based build
Date Fri, 06 Feb 2009 06:28:43 GMT
Chunrong,

Please don't be shy helping people with BTI. The help from Stepan and
Aleksey Varlamov (god praise their dedication to these fantastic
scripts) I got in addition to README was the most valuable and
welcome.

Thanks!

On Fri, Feb 6, 2009 at 5:15 AM, chunrong lai <chunronglai@gmail.com> wrote:
> On Thu, Feb 5, 2009 at 6:47 PM, Tim Ellison <t.p.ellison@gmail.com> 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
>>
>



-- 
С уважением,
Алексей Федотов,
ЗАО <<Телеком Экспресс>>

Mime
View raw message