CI

An overview of the environments and the virtual, and physical resources utilized for the xNVMe CI is illustrated below.

xNVMe CI environments and resources

Infrastructure

The main logical infrastructure component for the xNVMe CI is GitHUB Actions (GHA). GHA handles events occuring on the following repositories:

• xnvme/xnvme

• xnvme/xnvme.github.io

• xnvme/xnvme-docker

• xnvme/dpdk-windows-drivers

And decides what to execute and where. In other words GHA is utilized as a resource-scheduler and pipeline-engine. The executor role is delegated to CIJOE for details, then have a look at CIJOE in xNVMe.

The motivation for this separation is to make it simpler to reproduce build, test, and verfication issues occuring during a CI run, using locally available resources, by executing the CIJOE in xNVMe workflows and scripts.

Jobs

The jobs performed by the xNVMe CI catch the following issues during integration of changes / contributions:

• Code format issues

  • Linting and code-formating

  • clang-format for C

  • clippy for Rust

  • black / ruff for Python

• Build issues

  • On a rich collection of Linux Distributions

  • macOS 12, 13

  • Windows 2022

• Functional regressions

  • Running logical tests exercising all code-paths

  • Using a naive “ramdisk” backend

  • Using emulated NVMe devices via qemu

In addition to cathing issues, then the CI is also utilized for:

• Benchmarking of xNVMe

  • Using physical machines

  • Measure peak IOPS for a single physical CPU core

  • Specifically for the integration of xNVMe in SPDK (bdev_xnvme)

• Statically Analyze the C code-base

  • CodeQL via GitHUB

  • Coverity

• Produce and deploy documentation

  • Run all example commands (.cmd files) and collect their output in .out files

  • Render the Sphinx-doc documentation as HTML

  • Upload rendered documentation to xnvme.io via GitHUB-pages

These following sections provide system-setup notes and other details for the various CI jobs.