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 a SEAPATH operating system. To avoid many problems, all machines are already flashed with a Debian iso SEAPATH 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 All machines are 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 performed, 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
.
The CI performed the following tests:
- check regression on SEAPATH Ansible configuration by calling these Ansible playbooks as it will be in a regular SEAPATH setting up
- functional system tests, which check the OS configuration to unsure all machines are well configured and there are no regression
- hypervisor tests, to verify we can deploy VMs on hypervisors
- cluster tests, to check the cluster are well setup and the share storage works
- security tests, to unsure security hardening is correctly applied
- network connections tests, which verify that all network interface and all network works by making connections among them
- Quick IEC 61850 Sample values receptions and latency measurement tests
- PTP tests, to verify PTP clock is well synchronized in the host and the VM
No Real-time, complex IEC 61850, complex cluster tests or long times No Real-time or latency tests are run on the CI for now. We plan These tests are too long to be run on each GitHub pull request, so it is planned to integrate these tests at every release of the SEAPATH project.
Report
The CI can fail in two three ways :-
- The configuration of
...
- SEAPATH is wrong and the associated Ansible playbook fail
- The tests fail
...
- The
...
- tests on VM fail
The failure of the configuration can be observed in the CI logs.
...
The CI is actually running on the debian-main branch and on the 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.
...
Location of the link of the test report
Ansible's configuration have has fail, the tests were not launched, and the link was not given.
...
Hosting your own CI on SEAPATH first required having a cluster up and ready. All
You need:
- a SEAPATH cluster (all instructions for cluster configuration can be found on the SEAPATH architecture repository
...
- )
- a machine (or virtual machine) to host the GitHub runner
- a PTP clock
- a machine time synchronized with PTP clock with docker to host SV Tools (an IEC 61850 Sample Value simulator)
| Info |
|---|
IEC61850 HIL simulator is not needed because it is not used for the moment |
...
. |
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.
...