harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Geir Magnusson Jr <g...@pobox.com>
Subject Re: [build-test-infra] Build Test Infrastructure
Date Fri, 21 Jul 2006 13:09:21 GMT


Vladimir Ivanov wrote:
> I tried to use it. It is OK, but I have some comments on it. First of all,
> let me describe as I see the testing process:
> 
> - for developers:
> Before the commit of new feature/ fix the developer should run some
> 'pre-integration tests' (it may be unit tests) to be sure that workspace
> will not broken by commit. If developer have more than 1 platform it will
> nice to run these tests on different platforms.
> It is a base testing infrastructure for any project and Harmony already has
> it (for both - vm and api).

That is the assumption, right?  Every developer should already be doing
this.

> 
> Also, the "cruise control" systems on the target platforms over
> 'pre-integration tests' will be very useful just to check that the current
> workspace is OK (not all developers can check fixes on all target
> platforms).

Right

> 
> - for other community members (all peoples who want to help):
> If somebody wants to help to run tests he should download only the binary
> form of HDK, tests and script(s) to run it. Than he run all tests and
> upload/ emails results back. Of cause, these scripts should require minimum
> external tools (for example, 'ant' only).
> It is may be one time action for this member or time-to-time (depends on
> his
> wishes).
> 
> In this context seems a little bit discourteous to ask users to use the
> cruise control, svn, c/c++ compilers etc to run Harmony tests. On other
> side, for developers your system is a little bit excessive.

I don't agree that it's so black and white.  There's a valid point in
that some people might want to volunteer to run things, and that we can
minimize the tooling requirements.  But that can be solved easily :

1) we produce a snapshot of buildtest/
2) we add another configuration that fetches an HDK and runs the tests

(Actually, this is a good idea, and I look forward to seeing your patch!)

Seriously, that's not a bad idea, and it would only require having ant
and Java.  No need for SVN or other tools.


> 
> - for testing engineer (or somebody from developers):
> Looking through the result reports for different platforms, tries to
> reproduce detected failures and propose fixes for them.
> 
> Of cause, it is my thoughts only and may be it does not true, but I want to
> try to prepare testing scripts based on HDK (or snapshots of workspace) and
> tests archives.

it's not an either-or though.  See if you can consider using the
testbuild config - with a combination of a new ant target and different
config for CC - that does what you suggest - fetches  the HDK and runs
against it..

geir

> 
> Thanks, Vladimir
> On 7/12/06, Geir Magnusson Jr < geir@pobox.com> wrote:
>>
>>
>>
>> Alex Blewitt wrote:
>> > FWIW Mac OS X doesn't have tools.jar in $JAVA_HOME/lib. Instead, the
>> > tools are in the classes.jar file (no, it's not called rt.jar either)
>> > in $JAVA_HOME/../Classes/classes.jar. It's a bit unfortunate that it
>> > has both the run-time libraries and the tools in one place, but
>> > essentially it means that the sun tools are on the classpath whatever
>> > happens.
>> >
>> > Not that it's spectacularly relevant, but I thought I'd mention it
>> > here in case there's going to be a Mac port in the future ...
>>
>> What do you mean "in case"? :)  I'm hoping we can do that sooner rather
>> than later...
>>
>> geir
>>
>> >
>> > Alex.
>> >
>> >
>> > On 11/07/06, Geir Magnusson Jr < geir@pobox.com> wrote:
>> >>
>> >>
>> >> Richard Liang wrote:
>> >> >
>> >> > It seems that JAVA_HOME is required by cc/cruisecontrol.sh on my
>> Ubuntu
>> >> > :-)  Do I miss something? Thanks a lot.
>> >>
>> >> That seems to be the case :)  If you set it, does it work?
>> >>
>> >> It seems to want it for two things, tools.jar (for it's JSPs?) and
>> where
>> >> to find java executable.  The latter we just deal with (expect it
>> to be
>>
>> >> on the executable path), but tools is more interesting....
>> >>
>> >> geir
>> >>
>> >> ---------------------------------------------------------------------
>> >> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> >> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> >> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >>
>> >>
>> >
>> > ---------------------------------------------------------------------
>> > Terms of use : http://incubator.apache.org/harmony/mailing.html
>> > To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> > For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>> >
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> Terms of use : http://incubator.apache.org/harmony/mailing.html
>> To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
>> For additional commands, e-mail: harmony-dev-help@incubator.apache.org
>>
>>
> 

---------------------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org


Mime
View raw message