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"

(Option 1. Run Tests Again (after a successful build, you just want to re-run the same tests))
(Option 2. Run Tests separately from a build)
Line 30: Line 30:
 
Yes, that's it - just point at a pre-existing timestamp, and you're good to go!
 
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==
+
==Option 2. Run Tests Separately From a Previous Build==
  
 
Point your build.properties at the paths where the Tests and Update zips can be found.
 
Point your build.properties at the paths where the Tests and Update zips can be found.

Revision as of 18:57, 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 may 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 Previous 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