Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Difference between revisions of "Common Build Infrastructure/Testing"

(Run Tests In Hudson)
(Run Tests In Hudson)
Line 13: Line 13:
 
To use the new <code>testLocal</code> task, you will need to enable Xvnc to run around your entire build.
 
To use the new <code>testLocal</code> task, you will need to enable Xvnc to run around your entire build.
  
[[Image:Hudson-Enable-Xvnc-Wrapper.png]]
+
:[[Image:Hudson-Enable-Xvnc-Wrapper.png]]
  
 
To use the old <code>test</code> task, you will need to run your tests on a Linux server with xvnc or xvfb installed.
 
To use the old <code>test</code> task, you will need to run your tests on a Linux server with xvnc or xvfb installed.

Revision as of 18:55, 26 November 2009

Warning2.png
Draft Content
This page is currently under construction. Community members are encouraged to maintain the page, and make sure the information is accurate.


Running Tests As Part Of An Athena Build

Simply use these build.steps entries to build, then run, your tests. Or omit the property entirely in your build.properties file and the default steps will be run:

build.steps=buildUpdate,buildTests,generateDigests,testLocal,publish,cleanup

Note that the previous test runner task, "test" is still available but only works on Linux as it requires xvnc or xfvb.

Run Tests In Hudson

To use the new testLocal task, you will need to enable Xvnc to run around your entire build.

Hudson-Enable-Xvnc-Wrapper.png

To use the old test task, you will need to run your tests on a Linux server with xvnc or xvfb installed.

Running Tests Separately From An Athena Build

Option 1. Run Tests Again (after a successful build, you just want to re-run the same tests)

Point your build.properties at the previous build's timestamp and it will re-run the tests in that same folder (destructively).

build.steps=testLocal
buildTimestamp=200911232255

Yes, that's it - just point at a pre-existing timestamp, and you're good to go!

Option 2. Run Tests separately from a build

Point your build.properties at the paths where the Tests and Update zips can be found.

If you normally build with repositoryURLs and featureIDsToInstall, add the values below to those existing properties - DO NOT replace! You will of course need to define all the runtime/compiletime dependencies as you would for a normal build or build+test run.

Local Inputs

build.steps=testLocal,publish,cleanup
testFramework=/path/to/GEF-Automated-Tests-N200911232255.zip
repositoryURLs=jar:file:/path/to/GEF-Update-N200911232255.zip!/
featureIDsToInstall=${mainFeatureToBuildID}

Remote Inputs

build.steps=testLocal,publish,cleanup
testFramework=http://path/to/GEF-Automated-Tests-N200911232255.zip
repositoryURLs=http://path/to/GEF-Update-N200911232255.zip
featureIDsToInstall=${mainFeatureToBuildID}

To prevent cleanup, you can either omit the build.steps=publish,cleanup steps, or use

noclean=true

References

Back to the top