diff options
Diffstat (limited to 'contrib/cirrus/README.md')
| -rw-r--r-- | contrib/cirrus/README.md | 90 |
1 files changed, 41 insertions, 49 deletions
diff --git a/contrib/cirrus/README.md b/contrib/cirrus/README.md index 69d8653fe..18ef3e7f7 100644 --- a/contrib/cirrus/README.md +++ b/contrib/cirrus/README.md @@ -13,7 +13,6 @@ 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. - ### ``gating`` Task ***N/B: Steps below are performed by automation*** @@ -63,40 +62,11 @@ task (pass or fail) is set based on the exit status of the last script to execut Total execution time is capped at 2-hours (includes all the above) but this script normally completes in less than an hour. -### ``special_testing`` Task - -This task exercises podman under specialized environments or conditions. -The specific differences from the ``testing`` task depend upon the -contents of the ``$SPECIALMODE`` environment variable. - -| Value | Meaning | -| rootless | Setup a regular user to build/run integration tests. | -| in_podman | Setup a container image, build/run integration tests inside container | - -***N/B: Steps below are performed by automation*** - -1. After `gating` passes, spin up one VM per - `matrix: image_name` item. - -2. ``setup_environment.sh``: Mostly the same as - in ``testing`` task, then specialized depending on ``$SPECIALMODE``. - -3. Which tests and how they execute depends on ``$SPECIALMODE``. +### ``special_testing_cross`` Task -### ``optional_testing`` Task - -***N/B: Steps below are performed by automation*** - -1. Optionally executes in parallel with ``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. +Confirm that cross-compile of podman-remote functions for both `windows` +and `darwin` targets. ### ``test_build_cache_images_task`` Task @@ -131,10 +101,18 @@ images following the standard naming format; ***however, only runs a limited sub-set of automated tests***. Validating newly built images fully, requires updating ``.cirrus.yml``. -***Manual Steps:*** Assuming `verify_test_built_images` passes, then +***N/B: Steps below are performed by automation*** + +1. Using the just build VM images, launch VMs and wait for them to boot. + +2. Execute the `setup_environment.sh` as in the `testing` task. + +2. Execute the `integration_test.sh` as in the `testing` task. + + +***Manual Steps:*** Assuming the automated steps pass, then you'll find the new image names displayed at the end of the -`test_build_cache_images_task` in the `build_vm_images` output. -For example: +`test_build_cache_images`. For example: ``` @@ -169,20 +147,22 @@ the magic ``***CIRRUS: TEST IMAGES***`` string. Keeping it and `--force` pushing would needlessly cause Cirrus-CI to build and test images again. +### `release` Task -### ``build_cache_images`` Task *(Deprecated)* +Gathers up zip files uploaded by other tasks, from the local Cirrus-CI caching service. +Depending on the execution context (a PR or a branch), this task uploads the files +found to storage buckets at: -Exactly the same as ``test_build_cache_images_task`` task, but only runs on -the master branch. Requires a magic string to be in the `HEAD` -commit message: ``***CIRRUS: BUILD IMAGES***`` +* [https://storage.cloud.google.com/libpod-pr-releases](https://storage.cloud.google.com/libpod-pr-releases) +* [https://storage.cloud.google.com/libpod-master-releases](https://storage.cloud.google.com/libpod-master-releases) -When successful, the manifest file along with all VM disks, are moved -into a dedicated google storage bucket, separate from the one used by -`test_build_cache_images_task`. These may be used to create new cache-images for -PR testing by manually importing them as described above. +***Note:*** Repeated builds from the same PR or branch, will clobber previous archives + *by design*. This is intended so that the "latest" archive is always + available at a consistent URL. The precise details regarding a particular + build is encoded within the zip-archive comment. -### Base-images +## Base-images Base-images are VM disk-images specially prepared for executing as GCE VMs. In particular, they run services on startup similar in purpose/function @@ -193,10 +173,9 @@ as the standard 'cloud-init' services. with services pre-installed, for many platforms. For example, RHEL, CentOS, and Ubuntu. -* Google does ***not*** provide any images for Fedora or Fedora Atomic - Host (as of 11/2018), nor do they provide a base-image prepared to - run packer for creating other images in the ``build_vm_images`` Task - (above). +* Google does ***not*** provide any images for Fedora (as of 5/2019), nor do + they provide a base-image prepared to run packer for creating other images + in the ``test_build_vm_images`` Task (above). * Base images do not need to be produced often, but doing so completely manually would be time-consuming and error-prone. Therefor a special @@ -276,3 +255,16 @@ console output. Simply set the ``TTYDEV`` parameter, for example: $ make libpod_base_images ... TTYDEV=$(tty) ... ``` + +## `$SPECIALMODE` + +Some tasks alter their behavior based on this value. A summary of supported +values follows: + +* `none`: Operate as normal, this is the default value if unspecified. +* `rootless`: Causes a random, ordinary user account to be created + and utilized for testing. +* `in_podman`: Causes testing to occur within a container executed by + podman on the host. +* `windows`: See **darwin** +* `darwin`: Signals the ``special_testing_cross`` task to cross-compile the remote client. |