| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] ÐGSoCÑMay I ask for help h ere.
Dongxu Wang writes ("[Xen-devel] ÐGSoCÑMay I ask for help h ere."):
> So could you tell me who is the developer of the code? I want a few code or
> DB tables comments.
I wrote the code. I have already sent Dongxu a private email with
some notes about the test system but it seems useful to repeat them
here:
Each test run is called a "flight" and consists of a number of
mostly-independent "jobs". Jobs are the unit of execution and flights
are the unit of reporting.
A job can reuse data produced as output from another (completed job),
and sometimes they can share build hosts, but otherwise jobs are
executed independently.
A job is exected as a sequence of "steps"; each step consists of
running one of the individual test scripts "ts-*". The ts-* scripts
are largely written in Perl, and there are a couple of Perl modules
which are essentially grab bags of common functions.
Metadata is stored in a postgresql database. There's a dump of this
database here:
http://www.chiark.greenend.org.uk/~ijackson/volatile/2011/osstestdb.dump.gz
(To load this you may need to create dummy database users which mirror
the ones in my production database.)
Which steps to run in which order is determined by the Tcl programs
"sg-run-builds"/"sg-run-tests", which are invoked from
"sg-execute-flight", and depends on the job's "recipe" in the database.
The test scripts also rely on "runvars" which are a key/value listing
for each job.
"make-flight" creates a flight in the database, ready for execution by
sg-execute-flight, by calling some "cs-*" utility scripts.
"sg-report-flight" is generally run after a flight is finished. It
(a) analyses the results for the specified flight and/or tests of the
specified versions, and (b) produces textual and HTML output
(and exit status) describing the results. An example is here:
http://www.chiark.greenend.org.uk/~xensrcts/logs/6692/
There are also a bunch of other scripts and tools which aren't all
very relevant, eg: cron jobs and wrapper scripts which manage the
automatic pushing of tested revisions; resource allocation code which
allocates hosts to tests.
The "fancier web reporting" project would probably involve writing an
entirely separate web interface. sg-report-flight is too complicated
as a starting point because it's full of detailed analysis. Some
similar analysis might be useful in the web UI but probably with a
different approach - a user-driven one.
So really it's an exercise is reporting the information in the
"flights", "jobs" and "steps" tables. Also important is the "runvars"
table, because:
1. that controls how the scripts work and will need to be displayed
(see the existing static pages);
2. these runvars say which versions of the underlying code are used
(see the "*buildjob" runvars, which refer to either other jobs in the
same flight, or to jobs in other flights, and the "built_revision*"
variables in the referenced build job).
I hope that's of some use.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel
|
|
|
| |
|
Home