A System has been devised for testing and continuous integration using GitHub Workflows. By leveraging these tools, the SENSEI project is able to ensure the quality of the software when it is integrated into the ECP software stack.
An example using the GitHub Workflows can be found at os-linux.
The three main steps of the CI workflow are:
This step sets the stage for the rest of the downstream steps. Here we configure the build and tests for the OS and features the CI will test. For this, SENSEI uses a collection of modular CMake scripts that build the CMakeCache.txt. The name of the configuration is generally the same as the name of the job. In the example os-linux the job
linux-ecp using the configuration
The configuration is controlled by two environment variables
CMAKE_CONFIGURATION: This variable is required to be set. An example is
linux_ecpwhich is used for the
CMAKE_GENERATOR: This sets the generator cmake will use to build, the default generator is “Ninja”.
CMAKE_BUILD_TYPE: This sets the build type, the default build type is “Debug”.
- name: Configure
The build step is where SENSEI is built using all of the features specified by the configuration.
There are some environment variables that may be set for the CI job to modify how the build step performs.
CTEST_MAX_PARALLELISM: This limits the number of consequtive compilations tasks, for GitHub Actions this currently defaults to “2”.
- name: Build
The testing step is where the SENSEI tests are run. This includes the tests that use the miniapps and standalone drivers that test specific bridges. Depending on the features enabled during configuration, certain tests will be enable or disabled accordingly.
A note about GitHub Actions:
Due to that fact that GitHub Actions only provides two(2) cores for running CI it was decided to disable all tests that run with more than two(2) cores. Most of the tests marked
PARALLEL run with 4 cores, so the current method of disabling tests that use more than two(2) cores is to disable all tests labeld
PARALLEL if the environment variable
CTEST_MAX_PARALLELISM < four(4).
- name: Test
This last step is to store the result of the CI. This step is optional because it may not be desirable or needed to keep artifacts of the CI job around.
- name: "Upload Artifacts"
For an example of creating a new CI configuration that uses HDF5 and ADIOS2 and tests on a Linux OS, let’s call it
linux_hdf5_adios2. To get started we need a CMake configure file called
configure_linux_hdf5_adios2.cmake. This file will be located in the directory
The contents of this file will be pulling in the configurations for HDF5, ADIOS2, and Linux. Note the OS configuration always comes last as it will include additional configurations that may customize some settings based on the features that are configured. One example of this is VTK rendering.
Now that the configure file is setup, it is time to add a new job. Because this is a linux job, we will use the
sensei-ci:latest docker image. This image contains all of the possible dependencies for SENSEI that may be tested in CI. As more features are made available to CI additional jobs will be introduced to build and test them.
- Python 3
In the os-linux.yml a new job can be added under the
jobs section of the yaml.