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
|
# Cirrus-CI
Similar to other integrated github CI/CD services, Cirrus utilizes a simple
YAML-based configuration/description file: ``.cirrus.yml``. Ref: https://cirrus-ci.org/
## Workflow
All tasks execute in parallel, unless there are conditions or dependencies
which alter this behavior. Within each task, each script executes in sequence,
so long as any previous script exited successfully. The overall state of each
task (pass or fail) is set based on the exit status of the last script to execute.
### ``full_vm_testing`` Task
1. Unconditionally, spin up one VM per ``matrix: image_name`` item defined
in ``.cirrus.yml``. Once accessible, ``ssh`` into each VM and run the following
scripts.
2. ``setup_environment.sh``: Configure root's ``.bash_profile``
for all subsequent scripts (each run in a new shell). Any
distribution-specific environment variables are also defined
here. For example, setting tags/flags to use compiling.
3. ``verify_source.sh``: Perform per-distribution source
verification, lint-checking, etc. This acts as a minimal
gate, blocking extended use of VMs when a PR's code or commits
would otherwise not be accepted. Should run for less than a minute.
4. ``unit_test.sh``: Execute unit-testing, as defined by the ``Makefile``.
This should execute within 10-minutes, but often much faster.
5. ``integration_test.sh``: Execute integration-testing. This is
much more involved, and relies on access to external
resources like container images and code from other repositories.
Total execution time is capped at 2-hours (includes all the above)
but this script normally completes in less than an hour.
### ``optional_system_testing`` Task
1. Optionally executes in parallel with ``full_vm_testing``. Requires
**prior** to job-start, the magic string ``***CIRRUS: SYSTEM TEST***``
is found in the pull-request *description*. The *description* is the first
text-box under the main *summary* line in the github WebUI.
2. ``setup_environment.sh``: Same as for other tasks.
3. ``system_test.sh``: Build both dependencies and libpod, install them,
then execute `make localsystem` from the repository root.
### ``build_vm_images`` Task
1. When a PR is merged (``$CIRRUS_BRANCH`` == ``master``), Cirrus
checks the last commit message. If it contains the magic string
``***CIRRUS: REBUILD IMAGES***``, then this task continues.
2. Execute run another round of the ``full_vm_testing`` task (above).
After the tests pass (post-merge), spin up a special VM
(from the `image-builder-image`) capable of communicating with the
GCE API. Once accessible, ``ssh`` into the VM and run the following scripts.
3. ``setup_environment.sh``: Same as for other tasks.
4. ``build_vm_images.sh``: Utilize [the packer tool](http://packer.io/docs/)
to produce new VM images. Create a new VM from each base-image, connect
to them with ``ssh``, and perform the steps as defined by the
``$PACKER_BASE/libpod_images.json`` file:
1. On a base-image VM, as root, copy the current state of the repository
into ``/tmp/libpod``.
2. Execute distribution-specific scripts to prepare the image for
use by the ``full_vm_testing`` task (above). These scripts all
end with the suffix `_setup.sh` within the `$PACKER_BASE` directory.
3. If successful, shut down each VM and create a new GCE Image
named after the base image and the commit sha of the merge.
***Note:*** The ``.cirrus.yml`` file must be manually updated with the new
images names, then the change sent in via a secondary pull-request. This
ensures that all the ``full_vm_testing`` tasks can pass with the new images,
before subjecting all future PRs to them. A workflow to automate this
process is described in comments at the end of the ``.cirrus.yml`` file.
|
