You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@harmony.apache.org by sm...@apache.org on 2008/05/13 04:55:21 UTC
svn commit: r655715 - in /harmony/enhanced/buildtest/trunk/infra: README.txt
SPEC.txt
Author: smishura
Date: Mon May 12 19:55:20 2008
New Revision: 655715
URL: http://svn.apache.org/viewvc?rev=655715&view=rev
Log:
Update docs. to reflect latest framework changes
Modified:
harmony/enhanced/buildtest/trunk/infra/README.txt
harmony/enhanced/buildtest/trunk/infra/SPEC.txt
Modified: harmony/enhanced/buildtest/trunk/infra/README.txt
URL: http://svn.apache.org/viewvc/harmony/enhanced/buildtest/trunk/infra/README.txt?rev=655715&r1=655714&r2=655715&view=diff
==============================================================================
--- harmony/enhanced/buildtest/trunk/infra/README.txt (original)
+++ harmony/enhanced/buildtest/trunk/infra/README.txt Mon May 12 19:55:20 2008
@@ -13,7 +13,7 @@
Prepare
-------
-To get HY BTI working on your system, you should have the following tools
+To get Harmony BTI working on your system, you should have the following tools
installed:
1) JDK version 1.5.0:
@@ -36,34 +36,20 @@
Getting started
---------------
-To get started with HY BTI go through the points below. For quick start you
+To get started with Harmony BTI go through the points below. For quick start you
can skip long explanations - just read the headers of the items and execute
the commands started with #>
-1. Get the infrastructure from its SVN repository (located at @LINK):
-
- #> svn checkout -N -r HEAD @LINK
-
-Currently the link for HY BTI SVN repository is:
-
- https://svn.apache.org/repos/asf/harmony/enhanced/buildtest/branches/2.0
-
-It is important to use https protocol on this step: If you're running BTI on
-your workstation for a first time, this command will initially download
-SSL certificate from repository hosting site and ask for acceptance.
-To proceed you should accept the certificate permanently.
+1. Get the infrastructure from its SVN repository:
+ #> svn checkout http://svn.apache.org/repos/asf/harmony/enhanced/buildtest/trunk/infra
2. Install the BTI: Tune environment variables in buildtest scripts
-downloaded during the first step. And run the following command:
+downloaded during the first step, select test suites to execute and invoke
+install target. For example,
- #> buildtest install
-
-
-3. Select test suites to execute and setup your test run configuration:
-
- #> buildtest -Dtest.suites="classlib,drlvm,scimark" setup
+ #> buildtest -Dtest.suites="classlib,drlvm,scimark" install
This sample configuration means: execute classlib building (test that it can
be built), then on the base of built classlib do build of drlvm (test that it
@@ -82,10 +68,9 @@
look in adaptors/scimark/parameters.xml file: by default the scimark test
suite depends on drlvm: if drlvm and scimark are selected for test run
together, then scimark is always executed after drlvm and it takes JVM
-provided by drlvm as JVM to test. If drlvm test suite was not selected for
-run, then scimark's 'tested.runtime' "required" parameter won't be resolved
-and BTI will ask to provide this value by means of
-required-parameters.properties file.
+provided by drlvm as JVM to test. If drlvm test suite is not selected for
+run, then scimark's 'tested.runtime' "required" parameter is not resolved
+and BTI asks to provide this value in 'framework.local.properties' file.
drlvm test suite provides information about built JVM to other test suites
by means of "shared" 'jvm.location' parameter.
@@ -114,44 +99,30 @@
That's all about dependencies between the test suites.
-'buildtest setup' command generates required-parameters.properties file.
+'buildtest install' command generates required-parameters.properties file.
It contains all of the assignments of "required" parameters.
If some of the "required" parameters were not evaluated,
BTI will report an ERROR and demand to specify the values for
-unspecified parameters. You should whether provide them directly in
-required-parameters.properties file (this way is better for some predefined
-values, hardcoded path to tested JVM for example) and go to next step,
-or provide "required" to "shared" correspondence (as above) in
-framework.local.properties file and repeat 'buildtest setup'.
-
-Note: the values provided in required-parameters.properties take precedence
-over the values provided in parameters.xml or framework.local.properties
-files. So, if you change the values of required parameters in parameters.xml,
-or in framework.local.properties file, you should delete corresponding
-required parameter from required-parameters.properties file.
-
-For example of usage of the required-parameters.properties file let's look at
-the configuration containing only scimark test suite:
-'buildtest -Dtest.suite=scimark setup' command will end with demand to specify
-the value for 'scimark.tested.runtime' "required" parameter. We just write the
-following line in required-parameters.properties file:
+unspecified parameters. You should provide them directly in
+framework.local.properties file and repeat 'buildtest install'.
-scimark.tested.runtime=/usr/bin/java
+3. Setup test suites:
-and go to the next point of the usage guide.
+ #> buildtest setup
+This command launches setup target for each installed suite.
4. To launch the configured test run, type the following:
#> buildtest run
-It will execute selected test suites. BTI will execute each of the suites and
-report SUCCESS if there were no test failures and ERROR otherwise.
+It executes selected test suites. BTI executes each of the suites and
+reports SUCCESS if there are no test failures and ERROR otherwise.
To launch continuous test run, type the following:
#> buildtest run-cc
-It will launch CC controlled continuous test execution. There are two modes of
+It launches CC controlled continuous test execution. There are two modes of
continuous execution: SVN modifications triggered and scheduled runs. SVN
modifications triggered runs are executed each time SVN modification occurs.
The SVN repositories controlled by test suites are defined by cc.usesvn*
@@ -161,7 +132,7 @@
framework.parameters.schedule.day=Tuesday
- Do launch test suites execution on particular day.
- If this property is not defined, the test run will be launched everyday.
+ If this property is not defined, the test run is launched everyday.
framework.parameters.schedule.time=1530
- Do launch test suites execution at this particular time.
Should be defined for scheduled execution mode.
Modified: harmony/enhanced/buildtest/trunk/infra/SPEC.txt
URL: http://svn.apache.org/viewvc/harmony/enhanced/buildtest/trunk/infra/SPEC.txt?rev=655715&r1=655714&r2=655715&view=diff
==============================================================================
--- harmony/enhanced/buildtest/trunk/infra/SPEC.txt (original)
+++ harmony/enhanced/buildtest/trunk/infra/SPEC.txt Mon May 12 19:55:20 2008
@@ -35,6 +35,8 @@
suite depends.
* <shared>
used for sharing some values with other suites.
+ * <svn>
+ specifies SVN locations used by a suite.
* <cc>
used to describe some parameters used for default
Cruise Control configuration (example: use SVN checks on the test
@@ -75,7 +77,7 @@
</external>
</parameters>
--------------------------------------------------------
- the following set of properties will be set:
+ the following set of properties is defined:
my-test-suite.parameters.external.junit-3.8.1.md5=1f40fb782a4f2cf78f161d32670f7a3a
my-test-suite.parameters.shared.build.dir=${sources.dir}/target
@@ -96,31 +98,17 @@
(such as: path to tested classlib, jvm and so on)
1. In case of unspecified value for some of the 'required' parameters,
- BT framework will report it and won't launch the selected test suites
+ BT framework reports about it and doesn't launch the selected test suites
2. All of the required parameters for selected test suites are collected in
${root.dir}/required-parameters.properties
- file. This file is generated by framework on 'setup' stage and
+ file. This file is generated by framework on 'install' stage and
should be used for specification of the values for
unset required parameters.
-----
Note: ${root.dir}/required-parameters.properties file should not be
- ----- used for specification of the values for properties other
- than 'required'. If you will add your property to this file,
- BT framework will warn you about it and remove this property
- from this file. Your property with its value will be saved into
- ${root.dir}/backup-parameters.properties
- file. You SHOULD use
- ${root.dir}/framework.local.properties
- file for setting up the properties other than required.
-
- 3. Any required parameters values specified for unselected test suites
- will be saved in
- ${root.dir}/backup-parameters.properties
- file. If you want to reuse these values, do copy/paste from this file
- to
- ${root.dir}/required-parameters.properties
- file.
+ ----- updated manually. All unset required properties should be
+ defined in framework.local.properties file.
o Required Parameters Specification and Dereferencing
@@ -138,7 +126,7 @@
...
--------------------------------------------------------
-----
- Note: Without description your parameter won't be considered as
+ Note: Without description your parameter is not considered as
----- required.
2. Inside the my-test-suite/adaptor.xml this parameter can be accessed by
@@ -148,11 +136,11 @@
- by using of its short name with 'my-test-suite' prefix:
${my-test-suite.req.param}
- by using of extended parameter name:
- ${my=test-suite.parameters.required.req.param}
+ ${my-test-suite.parameters.required.req.param}
3. Inside the 'Required Parameters Specification File':
${root.dir}/required-parameters.properties
- this parameter will be in short form prefixed with suite's name.
+ this parameter is in extended form.
o Default Values for Required Parameters
@@ -176,9 +164,9 @@
...
--------------------------------------------------------
- 4. If the 'some-other-test-suite' was not selected for run, the value
- for this parameter will be unspecified and demanded for specification
- by framework either on 'run' or on 'setup' stage.
+ 4. If the 'some-other-test-suite' is not selected for run, the value
+ for this parameter is unset and requested for specification
+ by framework on 'install' stage.
o Shared Parameters
@@ -195,11 +183,11 @@
o External Libraries Dependencies
- New BT Infratructure offers the common way to fetch, use and share external
- libraries between the test suites. Ii is done by the following means:
+ BT Infratructure offers the common way to fetch, use and share external
+ libraries between the test suites. It is done by the following means:
- every external dependency for the test suite is described in defined
format in parameters.xml file
- - BT on 'setup' stage fetches all the dependencies according to their
+ - BT on 'install' stage fetches all the dependencies according to their
descriptions and sets up corresponding properties to access them.
- adaptors uses these properties to pass the information about fetched
libraries to the test suites.
@@ -214,7 +202,7 @@
1. The base mode for test suite execution launched by 'run' target is a
single run of each of the selected test suites.
- 2. The order in which the test suites will be launched depends on the
+ 2. The order in which the test suites are launched depends on the
dependencies between the suites. Such a dependencies are specified in
parameters.xml by 'depends' attribute of the root 'parameters' tag.
The value of this attribute should be a coma separated list of all the
@@ -232,27 +220,26 @@
o Default CC Configuration
- * By default CC run all af the selected test suites are executad as a
+ * By default CC run all if the selected test suites are executed as a
separate CC Project with the following configuration:
1. Launching of the suite for execution is made by means of
adaptor's run target.
2. If the set of dependencies for this suite is not empty, this suite
- will monitor the build status of these suites al will be launched
- for execution (by means of adaptor's run target) in case of succesfull
- build of superior suites.
+ monitors the build status of these suites is launched for execution
+ in case of succesfull build of superior suites.
3. If there is a 'usesvn' attribute specified for <cc> element of
parameters.xml file, the path contained as a value of this attribute
- will be monitored for changes as a SVN repository. And if there was
- some update for this repository, this update will be autimatically
- fetched and test suite will be launched for execution.
+ is monitored for changes in a SVN repository. And if there is
+ some update for this repository, this update is autimatically
+ fetched and test suite is launched for execution.
4. If there is a 'trigger' attribute specified for <cc> element of
parameters.xml file, the path to file contained as a value of this
- attribute will be monitored for the modifications. And if there was
- a modification for this file, the test suite will be launched for
+ attribute is monitored for the modifications. And if there is
+ a modification for this file, the test suite is launched for
execution.
o Custom CC Configuration
@@ -279,10 +266,10 @@
- The section <schedule> of the custom CC-config file MUST contain
the following tag:
<!-- @BT.ADAPTORCALL@ -->
- This tag will be resolved to the code performing the call to the
+ This tag is resolved to the code performing the call to the
adaptor run target to launch suite for execution.
- - Before using, this custom config file will be copied by BT to
+ - Before using, this custom config file is copied by BT to
another place and to another name. So the paths to the external
files in custom CC-config file SHOULD be absolute names, or use
global framework's properties (such as ${root.dir},