Skip to content
Zeke Morton edited this page Dec 10, 2021 · 8 revisions

Exawork Software Development Kit

Continuous Integration

LLNL CI

The SDK components are tested on LLNL machines using Gitlab Continuous Integration pipelines. The pipe consists of two parallel testing tracks: Container testing and bare metal testing by way of Spack.

Container Testing

Container tests are carried out through a 3 stage pipeline to build base and core images, and run the test suite. The pipeline uses a parallel matrix to build the SDK components with different hyper-parameters, varying the OS and MPI flavor. The images are stored in Quay image repository. What appear to be network issues sometimes cause failure when accessing Quay, so retry logic was added to the pipeline in the event of this specific type of failure. Some future work on this effort may be to reduce the number of total containers created by combining all 4 core packages into the same container image.

Bare Metal Testing with Spack

Bare metal tests are carried out through a 3 stage pipeline. The Build stage utilizes Spack to build the ExaWorks meta package. There seem to be intermittent issues when fetching packages with the default configuration, so changing the value for url_fetch_method to curl in the spack config.yaml is recommended. The test stage runs some basic smoke tests that are adapted from the container tests. These test will be expanded in the future. The third stage cleans and removes the spack environment.

Testing

The SDK components are tested using the Test Anything Protocol.

Python tests built with pytest can be output as TAP by installing the pytest-tap package and then adding the --tap-stream flag to pytest when running.

Python tests built with unittest can be output as TAP by adding a TestRunner such as pycotap.

Packaging

Spack

Spack package creation tutorial: https://spack-tutorial.readthedocs.io/en/latest/tutorial_packaging.html

Highlighted steps of the package creation

1. Spack installation
git clone https://github.com/spack/spack.git
. spack/share/spack/setup-env.sh
2. Create Spack package recipe by the template
# spack create <path-to-tarball>
spack create https://github.com/radical-cybertools/radical.pilot/archive/refs/tags/v1.8.0.tar.gz
# package template will be created here (all python packages starts with "py-"): 
#   <path-to-spack>/spack/var/spack/repos/builtin/packages/py-radical-pilot/package.py
3. Notes for recipe editing
  • If package dependencies are not in Spack, they should be added as well;
  • Variable maintainers is a list of GitHub usernames, who are responsible to maintain a corresponding Spack package (they should consented to be maintainers);
  • Function call version('develop', branch='devel') maps Spack package version develop to the corresponding GitHub branch (GitHub URL of the project should be set with git variable);
  • Function call depends_on lists hard requirements, not soft preferences;
  • Not supported version of the package should be described with deprecated=True set and shouldn't be removed from the recipe;
4. Submit created package recipe
  1. Fork Spack GitHub repository (https://github.com/spack/spack.git);
  2. Submit created package back to Spack as a Pull Request;

Spack packages list: https://spack.readthedocs.io/en/latest/package_list.html