Slurm Test Environments

Dockerized environments for testing software against a variety of Slurm versions.

Working with Images

Refer to the sections below for examples on using the Slurm test environments in different situations.

Pulling Existing Images

Published images are stored on the GitHub container registry and can be downloaded using docker. For instructions on authenticating against the GitHub registry, see the official docs.

The test_env image can be pulled using standard docker commands:

docker pull ghcr.io/pitt-crc/test-env

The default latest tag points to image with the most recent Slurm version. This is not always the same as the version most recently published by Slurm. Specific Slurm versions can be requested by specifying the version as a tag. See here for all available tags.

Building an Image Locally

You will need to enable Docker Buildkit to build the image. To do so, export the following environmental variable:

export DOCKER_BUILDKIT=1

The Dockerfile is designed to be reusable for different Slurm versions. The Slurm version needs to be specified when building an image. The following example builds an image called test_env:local using Slurm version 23.02.5:

docker build --build-arg SLURM_VERSION=23.02.5 -t test_env:local .

For a list of valid Slurm version tags, see the SLURM config directory in this repository.

Once you have built an image, the test suite can be run from within the docker container:

docker run  -i -v $(pwd)/tests:/tests test_env:local bats /tests

Using Images in GitHub Actions

To run a GitHub actions job from within a container, specify the container option. GitHub actions will not automatically launch the container entrypoint. Instead, you should include a dedicated setup step as follows:

jobs:
  example_job:
    runs-on: ubuntu-latest
    container:
      image: ghcr.io/pitt-crc/test-env:23.02.5

    steps:
      - name: Setup environment
        run: /usr/local/bin/entrypoint.sh

If you want to run a job several times using different containers (e.g., to test software against multiple Slurm versions) use the strategy directive:

jobs:
  example_job:
    runs-on: ubuntu-latest
    strategy:
      fail-fast: false
      matrix:
        slurm_version:
          - "20.11.9"
          - "22.05.2"
          - "22.05.11"
          - "23.02.5"
        python_version:
          - "3.9"
          - "3.10"
          - "3.11"
          - "3.12"

    container:
      image: ghcr.io/pitt-crc/test-env:${{ matrix.slurm_version }}

    steps:
      - name: Setup environment
        run: /usr/local/bin/entrypoint.sh

Testing Fixtures

The test environment comes partially configured with various tools, running services, and mock data. All images are built using the Rocky 8 operating system.

Slurm Configuration

The installed Slurm instance is configured with the following clusters, partitions, and nodes:

Cluster Name	Partition Name	Nodes
development	partition1	c[1-5]
development	partition2	c[6-10]

The following Slurm accounts are also included:

Account Name	Slurm Description	Slurm Organization
account1	account1_desc	account1_org
account2	account2_desc	account2_org

Running services

The following services are automatically launched when spinning up a new container:

• mariadb
• munge
• slurmdbd
• slurmctld
• slurmrestd

Python versions

Python versions 3.9 through 3.12 are included in the test environment, each having dedicated a dedicated pip3.x installation.

General Utilities

The following commandline tools are explicitly provided in the testing environment.

• which (Required for compatibility with some IDE docker integrations)
• bats
• make