~auto-package-testing-dev/auto-package-testing/trunk

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
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
auto-package-testing
====================

Overview
========
auto-package-testing is a set of helper scripts around autopkgtest to easily
setup a clean testbed for autopkgtest and run package tests automatically or
manually.


Pre-requisites
==============
The following packages must be installed on the host system:

 * bzr
 * distro-info
 * qemu-utils
 * kvm
 * eatmydata

Then branch the project from bazaar:
    
    $ bzr branch lp:auto-package-testing
    $ cd auto-package-testing

And provision a Quantal AMD64 system:

    $ ./bin/prepare-testbed -r quantal -d amd64

This command will create a pristine Quantal AMD64 VM from a cloud image.


Running the tests
=================

Testing a package in the archive
--------------------------------

The most basic command is to run the tests for a package in the archive. The
following example runs sphinx testsuite on Quantal AMD64.

    $ ./bin/run-adt-test -r quantal -a amd64 sphinx

The results are copied to the host in following directory:

    /tmp/quantal-amd64-sphinx-<TIMESTAMP>/<TIMESTAMP>/results

This directory contains all the test artifacts. Interesting files are:

 * log: Output of autopkgtest
 * *.stdout: output of the test to stdout
 * *.stderr: output of the test to stderr

Testing a package in a PPA
--------------------------

The following command enables a ppa and test the package 'friends':

    $ ./bin/run-adt-test -r quantal -d -a amd64 -p ppa:super-friends/daily friends


Building and testing from source
--------------------------------

The option -S supports testing from a source tree. Currently supported source
locations are:

  * Download source from apt: -S apt
  * Local directory tree: -S file://<path to source tree>
  * Launchpad bazaar branch: -S lp:<branch location>
  * Git repository: -S git:<repository>

For example, the following command enables pulls a branch from bazaar, build
the package and run the testsuite:

    $ ./bin/run-adt-test -S lp:~super-friends/friends/packaging

If your branch merely adds tests to a package, and you do not want to build it
and instead run the tests against the current distribution package, specify the
package name explicity:

    $ ./bin/run-adt-test -S lp:~super-friends/friends/packaging friends

This other example copies a local directory to the sandbox and runs the tests
from there:

    $ ./bin/run-adt-test -S /tmp/work/pkgs/tabix


Testing a package from a PPA with the test in a packaging branch
----------------------------------------------------------------

The command below enabled a PPA, pulls a packaging branch and runs the tests
described in the DEP8 control file in the packaging branch against the binary
package from the PPA:

    $ ./bin/run-adt-test -r quantal -d -a amd64 -p ppa:super-friends/daily -b lp:~super-friends/friends/packaging friends


Hacking inside the testbed
--------------------------

If you start the testbed and login, to work on your test or troubleshoot test
failures, the following command will start the testbed and prepare it so you can
run adt-run directly:

    $ ./bin/run-adt-test -r quantal -a amd64 -S -l apport

 * -S will install the sources of apport
 * -l will log you in

Once you're logged in, you'll get a shell with byobu window manager and you can run apport test from the source tree with:

    $ cd apport*
    $ sudo adt-run --unbuilt-tree . --- adt-virt-null

Be careful to copy your work outside of the testbed before exiting, as the
testbed will be destroyed on exit. You can keep the testbed after the run with
the option '-k'.

Serial console
--------------
If anything you do in the VM manages to crash the network or tear down eth0,
ssh access to the VM will not work any more. In this case you can log in
through a serial console which is exposed as an Unix socket in
$BASEDIR/<image_overlay>.img.serial. I. e. /run/shm/adt/*.img.serial if you use
-s, or /tmp/adt/*.img.serial if not (unless you change $BASEDIR in your
~/.adtrc). Connect to it with e. g. netcat or minicom:

  nc -U /run/shm/adt/*.img.serial
  minicom -D unix#`ls /run/shm/adt/*.img.serial`

Right next to the *.serial socket is also a *.monitor socket which is the QEMU
monitor. You can connect there if you want to do QEMU operations like changing
the hardware or shutting down.