OLD | NEW |
---|---|
(Empty) | |
1 Test suite runner for V8, including support for distributed running. | |
2 ==================================================================== | |
3 | |
4 | |
5 Local usage instructions: | |
6 ========================= | |
7 | |
8 Run the main script with --help to get detailed usage instructions: | |
9 | |
10 $ tools/run-tests.py --help | |
11 | |
12 The interface is mostly the same as it was for tools/test-wrapper-gypbuild.py. | |
Michael Starzinger
2012/09/21 13:20:40
Since the old script was just a temporary wrapper,
Jakob Kummerow
2012/09/21 17:02:24
Done.
| |
13 You'll likely want something like this: | |
14 | |
15 $ tools/run-tests.py --nonetwork --arch ia32 --mode release | |
16 | |
17 --nonetwork is the default on Mac and Windows. If you don't specify --arch | |
Michael Starzinger
2012/09/21 13:20:40
Can we make --nonetwork the default on Linux too?
Jakob Kummerow
2012/09/21 17:02:24
Yes, if the server is not running it falls back si
| |
18 and/or --mode, all available values will be used and run in turn (e.g., | |
19 omitting --mode from the above example will run ia32 in both Release and Debug | |
20 modes). | |
21 | |
22 | |
23 Networked usage instructions: | |
24 ============================= | |
25 | |
26 Networked running is only supported on Linux currently. Make sure that all | |
27 machines participating in the cluster are binary-compatible (e.g. mixing | |
28 Ubuntu Lucid and Precise doesn't work). | |
29 | |
30 Setup: | |
31 ------ | |
32 | |
33 1.) Copy tools/server.py to a new empty directory anywhere on your hard drive | |
Michael Starzinger
2012/09/21 13:20:40
Does symlinking work? If yes that would be awesome
Jakob Kummerow
2012/09/21 17:02:24
Done.
| |
34 (preferably not inside your V8 checkout just to keep things clean). | |
35 | |
36 2.) Navigate to the new directory and let the server setup itself: | |
37 | |
38 $ ./server.py setup | |
39 | |
40 This will install PIP and UltraJSON, create a V8 working directory, and | |
41 generate a keypair. | |
42 | |
43 3.) Swap public keys with someone who's already part of the networked cluster. | |
44 | |
45 $ cp trusted/`cat data/mypubkey`.pem /where/peers/can/see/it/myname.pem | |
46 $ ./server.py approve /wherever/they/put/it/yourname.pem | |
47 | |
48 | |
49 Usage: | |
50 ------ | |
51 | |
52 1.) Start your server: | |
53 | |
54 $ ./server.py start | |
55 | |
56 2.) (Optionally) inspect the server's status: | |
57 | |
58 $ ./server.py status | |
59 | |
60 3.) From your regular V8 working directory, run tests: | |
61 | |
62 $ tool/run-tests.py --arch ia32 --mode debug | |
63 | |
64 4.) (Optionally) enjoy the speeeeeeeeeeeeeeeed | |
65 | |
66 | |
67 Architecture overview: | |
68 ====================== | |
69 | |
70 Code organization: | |
71 ------------------ | |
72 | |
73 This section is written from the point of view of the tools/ directory. | |
74 | |
75 ./run-tests.py: | |
76 Main script. Parses command-line options and drives the test execution | |
77 procedure from a high level. Imports the actual implementation of all | |
78 steps from the testrunner/ directory. | |
79 | |
80 ./server.py: | |
Michael Starzinger
2012/09/21 13:20:40
I am not sure about the name of this script. How a
Jakob Kummerow
2012/09/21 17:02:24
Done.
| |
81 Interface to interact with the server. Contains code to setup the server's | |
82 working environment and can start and stop server daemon processes. | |
83 Imports some stuff from the testrunner/server/ directory. | |
84 | |
85 ./testrunner/local/*: | |
86 Implementation needed to run tests locally. Used by run-tests.py. Inspired by | |
87 (and partly copied verbatim from) the original test.py script. | |
88 | |
89 ./testrunner/local/old_statusfile.py: | |
90 Provides functionality to read an old-style <testsuite>.status file and | |
91 convert it to new-style syntax. This can be removed once the new-style | |
92 syntax becomes authoritative (and old-style syntax is no longer supported). | |
93 ./status-file-converter.py provides a stand-alone interface to this. | |
94 | |
95 ./testrunner/objects/*: | |
96 A bunch of data container classes, used by the scripts in the various other | |
97 directories; serializable for transmission over the network. | |
98 | |
99 ./testrunner/network/*: | |
100 Equivalents and extensions of some of the functionality in ./testrunner/local/ | |
101 as required when dispatching tests to peers on the network. | |
102 | |
103 ./testrunner/network/network_execution.py: | |
104 Drop-in replacement for ./testrunner/local/execution that distributes | |
105 test jobs to network peers instead of running them locally. | |
106 | |
107 ./testrunner/network/endpoint.py: | |
108 Receiving end of a network distributed job, uses the implementation | |
109 in ./testrunner/local/execution.py for actually running the tests. | |
110 | |
111 ./testrunner/server/*: | |
112 Implementation of the daemon that accepts and runs test execution jobs from | |
113 peers on the network. Should ideally have no dependencies on any of the other | |
114 directories, but that turned out to be impractical, so there are a few | |
115 exceptions. | |
116 | |
117 ./testrunner/server/compression.py: | |
118 Defines a wrapper around Python TCP sockets that provides JSON based | |
119 serialization, gzip based compression, and ensures message completeness. | |
120 | |
121 | |
122 Networking architecture: | |
123 ------------------------ | |
124 | |
125 The distribution stuff is designed to be a layer between deciding which tests | |
126 to run on the one side, and actually running them on the other. The frontend | |
127 that the user interacts with is the same for local and networked execution, | |
128 and the actual test execution and result gathering code is the same too. | |
129 | |
130 The server daemon starts four separate servers, each listening on another port: | |
131 - "Local": Communication with a run-tests.py script running on the same host. | |
132 The test driving script e.g. needs to ask for available peers. It then talks | |
133 to those peers directly (one of them will be the locally running server). | |
134 - "Work": Listens for test job requests from run-tests.py scripts on the network | |
135 (including localhost). Accepts an arbitrary number of connections at the | |
136 same time, but only works on them in a serialized fashion. | |
137 - "Status": Used for communication with other servers on the network, e.g. for | |
138 exchanging trusted public keys to create the transitive trust closure. | |
139 - "Discovery": Used to detect presence of other peers on the network. | |
140 In contrast to the other three, this uses UDP (as opposed to TCP). | |
141 | |
142 | |
143 Give us a diagram! We love diagrams! | |
144 ------------------------------------ | |
145 . | |
146 Machine A . Machine B | |
147 . | |
148 +------------------------------+ . | |
149 | run-tests.py | . | |
150 | with flag: | . | |
151 |--nonetwork --network | . | |
152 | | / | | . | |
153 | | / | | . | |
154 | v / v | . | |
155 |BACKEND / distribution | . | |
156 +--------- / --------| \ ------+ . | |
157 / | \_____________________ | |
158 / | . \ | |
159 / | . \ | |
160 +----- v ----------- v --------+ . +---- v -----------------------+ | |
161 | LocalHandler | WorkHandler | . | WorkHandler | LocalHandler | | |
162 | | | | . | | | | | |
163 | | v | . | v | | | |
164 | | BACKEND | . | BACKEND | | | |
165 |------------- +---------------| . |---------------+--------------| | |
166 | Discovery | StatusHandler <----------> StatusHandler | Discovery | | |
167 +---- ^ -----------------------+ . +-------------------- ^ -------+ | |
168 | . | | |
169 +---------------------------------------------------------+ | |
170 | |
171 Note that the three occurrences of "BACKEND" are the same code | |
172 (testrunner/local/execution.py and its imports), but running from three | |
173 distinct directories (and on two different machines). | |
OLD | NEW |