@@ -619,8 +619,8 @@ ExecutiveDbOwningRoleRegexp
changes - because, that role will end up owning the database objects.
Defaults to `osstest'.
-Adhoc/Custom Flights
-====================
+Flights for by-hand testing
+===========================
Normally a flight is constructed using "make-flight", either via
"./standalone make-flight" or by calling make-flight (or another
@@ -638,14 +638,14 @@ A fresh empty flight is created by using the "cs-flight-create"
script. It takes as arguments a "blessing" and a "branch" and on
success prints the new flight number.
-The blessing should almost always be "adhoc". The branch doesn't
+The blessing should almost always be "play". The branch doesn't
really matter, if you are testing something related to a failure on a
-given branch you may as well use that, otherwise "adhoc" or
+given branch you may as well use that, otherwise "play" or
"xen-unstable" is a reasonably fallback.
Thus the normal way to invoke cs-flight-create is:
- $ flight=`./cs-flight-create adhoc adhoc`
+ $ flight=`./cs-flight-create play play`
Which results in a $flight which can be used for the remainder of the
configuration.
@@ -687,20 +687,20 @@ run-job/$recipe" which runs the required test steps. There are plenty
of examples in sg-run-job.
Once the flight is created it is run using mg-execute-flight. It is
-usual to pass -Badhoc (to set the target blessing) and -Eemail to set
+usual to pass -Bplay (to set the target blessing) and -Eemail to set
the destination for the test report as well as giving the flight:
- $ ./mg-execute-flight -Badhoc -Eemail@example.com $flight
+ $ ./mg-execute-flight -Bplay -Eemail@example.com $flight
A worked example, including a custom recipe (in this case to reboot
Xen five times on the host) and .
-Custom sg-run-job-adhoc, requires a single host (ident "host") and
+Custom sg-run-job-play, requires a single host (ident "host") and
runs ts-host-reboot + a ping check 5 times:
----START-------
-proc need-hosts/adhoc-xen-boot-x5 {} { return host }
-proc run-job/adhoc-xen-boot-x5 {} {
+proc need-hosts/play-xen-boot-x5 {} { return host }
+proc run-job/play-xen-boot-x5 {} {
repeat-ts 5 xen-boot.repeat \
ts-host-reboot host \; \
ts-host-ping-check host
@@ -719,13 +719,13 @@ lnxrev=<some revision of Linux which we want to test>
template=123456
# Create the flight
-flight=`./cs-flight-create adhoc adhoc`
+flight=`./cs-flight-create play play`
echo $flight
# Create a test job from scratch, many of the runvars cribbed from a
# random job in a real flight created by make-flight.
-job=adhoc-amd64-amd64-xen-boot
-./cs-job-create $flight $job adhoc-xen-boot-x5 \
+job=play-amd64-amd64-xen-boot
+./cs-job-create $flight $job play-xen-boot-x5 \
all_hostflags=arch-amd64,arch-xen-amd64,suite-wheezy,purpose-test \
arch=amd64 toolstack=xl enable_xsm=false kernkind=pvops \
host=$host
@@ -746,5 +746,5 @@ job=adhoc-amd64-amd64-xen-boot
./cs-adjust-flight $flight runvar-set $job kernbuildjob build-amd64-pvops
# Now run the job.
-./mg-execute-flight -Badhoc -Eme@example.com $flight
+./mg-execute-flight -Bplay -Eme@example.com $flight
----END---------
Any flight eventually blessed `adhoc' is supposed to contain, in the db, accurate information corresponding to a real clean run. This is not appropriate for playing about. Using `play' usefully disables a number of safety catches, including one which prevents post-startup flight modification. Signed-off-by: Ian Jackson <Ian.Jackson@eu.citrix.com> --- README | 28 ++++++++++++++-------------- 1 file changed, 14 insertions(+), 14 deletions(-)