1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
|
The new QA wrapper consistst mainly of 2 scripts, nssqa and qa_stat, both
include a common header (header) and a common environment (set_environment).
Also used is mksymlinks and path_uniq.
The scripts that are used on a daily basis are located in /u/sonmi/bin.
Parameters and Options are the same for both scripts.
Parameters
----------
nssversion (supported: 30b, 31, tip)
builddate (default - today, format mmdd)
Options
-------
-y answer all questions with y - use at your own risk... ignores warnings
-s silent (only usefull with -y)
-h, -? -help you guessed right - displays the usage
-d debug
-f <filename> - write the (error)output to filename
-m <mailinglist> - send filename to mailinglist (csl) only useful
with -f on nssqa
-l <mozroot> run on a local build - does not work at this time
-cron equivalient to -y -s -d -f $RESULTDIR/$HOST.<scriptname>
nssqa and qa_stat are Beta at the most
--------------------------
Please be aware that
-) machinenames are still hardcoded --FIXED
-) other very iPlanet specific environments and features are being used.
-d Debug option will be removed from cron in a few weeks - or maybe not
-l QA on local build is not fully implemented yet
Please do not use on Windows 95 and 98, ME platforms yet.
use -d if script behaves strange or exits unexpectedly
How to use QA
-------------
To test a build, first run nssqa on the required QA platforms (some
buildplatforms require QA to be run on additional platforms - for
example Solaris 2.6 has to be tested on 2.8 32 and 64bit) If QA has
been run on multiple or all required platforms it makes sense to run
qa_stat on the output of nssqa as well.
Before used on a new system (even if the same platform has been
tested before) please use completely interactive, to see what the
variables are being initialized to, and read the warnings. Same is
true if being run from a different user account than svbld.
In any case, if you are using it, please let me know the results.
Pseudocode Description of nssqa:
--------------------------------
not quite up to date
header:init (global)
set flags and variables to default values
signal trap (for interupts and kills)
set HOST and DOMSUF variables if running from cron
parse parameters and options
determine os and set up the environment (espec. PATH)
set the directories to run in (influenced by parameters and -l option)
set and initialize the tmp / debugging / output files
nssqa:init (local)
locking: if nssqa is already running on this systems (yes-exit,
no-lockfile)
set HOST and DOMSUF variables if running interavtively
set flag to kill remaining selfserv processes during cleanup
if QA platform different from build platform create neccessary
symbolic links
wait for the build to finish (max of 5h)
main:
repeated per test (optimized, debug, 32, 64 bit)
set flags for this run of all.sh (optimized, debug, 32, 64 bit)
set the DIST directory (where the binaries reside)
kill running selfservers (sorry - just don't use the svbld
account if you need to do your own testing... I will fix
selfserv as soon as I can - but it hangs too often and
disturbs all following QA)
run all.sh
header:exit (global)
remove temporary files
kill remaining selfservers
send email to the list
errorhandling
Option / Parameter errors: Exit with usage information
Severe errors: Exit wit errormessage
example: directory in which all.sh resides does not exist
can't create files or directories
build not done after 5 hours
is already running
Other errors: User is prompted with the "errormessage - continue (y/n)?"
example: local DIST dir does not exist (continues with next all.sh)
outputdirectory does not exist (user can specify other)
Signals 2, 3, 15 are treated as severe errors
|
