You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

Warning : This page is under maintenance and will be rewritten during the week


A continuous integration (CI) process has been implemented in order to deploy and test a custom cluster before merging any pull requests. Source code can be found in https://github.com/seapath/ci.

For now on, the CI is implemented for the Debian version of SEAPATH on the Ansible repository.

The CI is based on GitHub action and has been completely dockerized in order to guarantee its reproducibility and scalability.

Description

The CI operate on the Debian operating system. To avoid many problems, all machines are already flashed with a Debian iso and the CI will only configure the systems using the Ansible playbooks. This implies the iso creation and the boot process can't be tested.

A cluster running Debian is configured and linked to a self-hosted runner, on which the GitHub Action for the CI will run.

The CI job is divided into different stages :
- Fetch the sources of the pull request to test
- Launch the Debian configuration and hardening using Ansible playbooks
- Deploy Cukinia and launch tests
- Generate and upload the test report

Tests

The CI use Cukinia, a system-level validation framework as testing tool, all tests launched on Debian are available at https://github.com/seapath/cukinia-tests/tree/main

Various Cukinia tests can be perform, and are split in following files:

  • cukinia-cluster: tests belonging to cluster (Peacemaker, CEPH  and VM tests)
  • cukinia-common: tests common to hypervisors and observers machines
  • cukinia-hypervisor: tests belonging to hypervisors machines
  • cukinia-observer: tests belonging to observers machines
  • cukinia-sec: security tests ; common to all machines
  • cukinia-sec-future: security tests on security measure not implemented yet

No Real-time or latency tests are run on the CI for now. We plan to integrate these tests at every release of the SEAPATH project.

Report

The CI can fail in two ways :
- The configuration of Debian is wrong and the associated Ansible playbook fail
- The non-regression tests fail

The failure of the configuration can be observed in the CI logs.

After the configuration, all tests will be gathered in a test report. All the test contained in the report must pass for the pull request to be merged.

Using the CI

The CI is actually running on the debian-main branch of the Ansible repository : https://github.com/seapath/ansible/tree/debian-main
Every pull request need to pass the tests to be merged.

After opening a pull request, wait for an approval of a member of SEAPATH. This will trigger the CI as a GitHub Action. The logs of the CI are visible on your pull request page, either in the "Conversation" tab or the "Checks" tab.
All running actions are also visible in the Actions tab on the repository.

The complete CI takes about 15 minutes. At the end, the test report is available through a link given in the log of the GitHub Action, at the end of the step "Launch test" step.


Access the logs of the CI on the pull request "Conversation" tab


Location of the link of the test report


Ansible's configuration have fail, the tests were not launched, and the link was not given.

Host your own CI

Preparing a cluster

Hosting your own CI on SEAPATH first required having a cluster up and ready. All instructions for cluster configuration can be found on the SEAPATH architecture repository.

Be aware that the CI is only available for the Debian version of the project for now.

Preparing the CI

The runner used to configure the machines will be used for the CI. Docker and cqfd are the only required software to launch it.

If you choose GitHub Actions to trigger the CI, you can follow this guide to link your self-hosted runner with your repository. Otherwise, another trigger has to be configured for the chosen CI solution.

The CI script launched with the CI is launch.sh on the SEAPATH CI repository. It will have to be adapted to fit with your repository links and your inventories and keys on your runner.

This section will be expanded in the future for a better understanding.




  • No labels