aa742e9e68
Previously, several magic strings were in place to affect cirrus-ci operations. Two were buried within scripts. One to optionally execute system-tests within a PR. Another to avoid re-building cache-images upon every merge. Move these magic strings out into the open, buy locating their logic up-front in the ``.cirrus.yml`` file. This improves readability and reduces surprise/astonishment at runtime. Signed-off-by: Chris Evich <cevich@redhat.com> |
||
---|---|---|
.. | ||
packer | ||
build_vm_images.sh | ||
integration_test.sh | ||
lib.sh | ||
ooe.sh | ||
optional_system_test.sh | ||
podbot.py | ||
README.md | ||
setup_environment.sh | ||
success.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.