2cc9b78ab9
Previously it was required to call the verify, unit, and integration scripts in order to build/install dependencies, and libpod. This wastes time during the (optional) system-testing, since the actual unit/integration testing is also happening in parallel. Consolidate only the distribution-specific build steps into the system-testing script. This way, only the required steps are performed in their respective (parallel) tasks. Signed-off-by: Chris Evich <cevich@redhat.com> |
||
---|---|---|
.. | ||
packer | ||
build_vm_images.sh | ||
integration_test.sh | ||
lib.sh | ||
ooe.sh | ||
podbot.py | ||
README.md | ||
setup_environment.sh | ||
success.sh | ||
system_test.sh | ||
unit_test.sh | ||
verify_source.sh |
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
-
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. -
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. -
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. -
unit_test.sh
: Execute unit-testing, as defined by theMakefile
. This should execute within 10-minutes, but often much faster. -
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.
build_vm_images
Task
-
When a PR is merged (
$CIRRUS_BRANCH
==master
), run another round of thefull_vm_testing
task (above). -
After confirming the tests all pass post-merge, spin up a special VM capable of communicating with the GCE API. Once accessible,
ssh
into the special VM and run the following scripts. -
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. -
build_vm_images.sh
: Examine the merged PR's description on github. If it contains the magic string***CIRRUS: REBUILD IMAGES***
, then continue. Otherwise display a message, take no further action, and exit successfully. This prevents production of new VM images unless they are called for, thereby saving the cost of needlessly storing them. -
If the magic string was found, utilize the packer tool to produce new VM images. Create a new VM from each base-image, connect to them with
ssh
, and perform these steps as defined by thelibpod_images.json
file.- Copy the current state of the repository into
/tmp/libpod
. - Execute distribution-specific scripts to prepare the image for
use by the
full_vm_testing
task (above). - If successful, shut down each VM and create a new GCE Image named after the base image and the commit sha of the merge.
- Copy the current state of the repository into
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.