A continuous continuous integration (CI) process has been implemented in order to build deploy and deploy test a custom cluster and automatise the periodical validation of the developmentbefore merging any pull requests. Source code can be found in https://github.com/seapath/ci.
The CI is based on a Jenkins server that GitHub action and has been completely dockerized in order to guarantee its reproducibility and scalability.
Remote actions are achieved thanks to Ansible playbooks.
Jenkins
Jenkins is an open source automation server that permits the periodical build, test, deployment or other tasks that need to be automated such as code synchronisation.
The main CI job can be divided into different stages:
- Fetch source code from SEAPATH GitHub.
- Build Yocto images for the cluster machines
- Flash the cluster machines with the he newly created images (this is done thanks to a PXE mechanism) and reboot them
- Configure the cluster
- Deploy the VMs on the cluster
As shown on the diagram, each step of the chain is validated with the corresponding Cukinia tests and results collected on the CI Jenkins server.
...
Description
The CI operate on a SEAPATH operating system. To avoid many problems, all machines are already flashed with 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.
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.
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 latency tests are run on the CI for now. 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 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.
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 and on the main branch of the Ansible repository
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 has 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.
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.
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
Jenkins offers a web UI to configure, manage and follow the progress of its jobs. As shown in the following picture, the stage view shows job information such the progress of the pipeline execution or the trend of the test results for the consecutive job executions.
Analyse tests result
The results of the Cukinia tests run on the cluster are retrieved and displayed on the Jenkins UI.
Blue Ocean View
The Blue Ocean plugin offers an intuitive UI that simplifies the view and edition of a pipeline. It also permits re-running stages for a determined build.
Log information
The complete output of a job execution can be obtained as well as the partial logs for each stage, as shown on the following picture.
RT test results
In order to validate the real-time requirements of the SEAPATH project, the CI also permits to execute cyclic tests on the VMs and retrieve the results.