Tinderbox/Tbox3 tests: Difference between revisions
m (Changed format a little.) |
m (→$client object: - formatting) |
||
Line 31: | Line 31: | ||
The $client object has a few function calls you'll probably want to use, as they help logging and facilitate using the framework tinderclient sets up for you. | The $client object has a few function calls you'll probably want to use, as they help logging and facilitate using the framework tinderclient sets up for you. | ||
; get_field :?? | |||
; do_command: The do_command method, in addition to doing a command, also adds it to the logs. | |||
:The do_command method, in addition to doing a command, also adds it to the logs. | ; eat_command :?? | ||
; print_log : This only adds a message to the log? | |||
This only adds a message to the log? | |||
==== TinderClientModules::YourModule::get_config ==== | ==== TinderClientModules::YourModule::get_config ==== |
Revision as of 21:13, 15 August 2005
Tinderbox 3 Builds and Tests
Mozilla specific tests
You shouldn't have much trouble running the supplied tinderclient - it's specifically set up for Mozilla.
Non-mozilla tests
Suppose you want to test building your application on a bunch of platforms and showing the results on Tinderbox. What do you have to do to set up the tests?
First, we assume you're using the tinderclient that was posted in the webtools newsgroup. I'll attach it here sometime.
Setup
In the tinderclient directory, there is a subdirectory TinderClientModules
. This directory holds Perl Modules that get called by tinderclient, based on options fed at the command line ("--module ..."). All you need to do is take the Template.pm, copy it to a new name, change the package
line of the module to match your name, and add code!
History, or How does Mozilla do it?
The original Mozilla specific tbox3 tinderclient has 4 modules that get run, one after the other:
- init_tree
- Pulls the code from CVS and prepares to build. If there are new changes that require a build, then
SHOULD_BUILD
is set; otherwise, it's left 0, so only the tests run continuoulsy if no one checks in code (this may be an oversight).
- build
- If
SHOULD_BUILD
is set, it will call "make" to make the build.
- distribute
- The distribute module looks at the argument (or Var) distribute, which defaults to "build_zip". Then for each module, if
SHOULD_BUILD
, it calls the module (which does a "make packager", or creates some other zip file), and then scps the build to the server.
- tests
- The tests module looked at the argument (or Var) "tests" (which defaults to "Tp,Ts,Txul") Then tests calls each of the arguments as a module (so TinderClient::Modules::Tp gets called, TinderClient::Modules::Ts, etc)
Details, Details, Details
$client object
The $client object has a few function calls you'll probably want to use, as they help logging and facilitate using the framework tinderclient sets up for you.
- get_field
- ??
- do_command
- The do_command method, in addition to doing a command, also adds it to the logs.
- eat_command
- ??
- print_log
- This only adds a message to the log?
TinderClientModules::YourModule::get_config
Not sure what this is used for yet.
TinderClientModules::YourModule::do_action
Here's where your client does it's stuff.
Return Codes
The success or failure of the do_action command is announced by the return code:
- 100-103: Success!
- 200-203: Various Failure codes.
- 301: ???
TinderClientModules::YourModule::finish_build
This is called one *all* of the do_action()s have been completed, and only if no errors were reported.