GitHub

GitHub Actions Runners

By default ASWF projects under the AcademySoftwareFoundation GitHub organization have access to the Standard GitHub-hosted runners for public repositories for Linux, Windows and macOS. Our GitHub organization qualifies as an Enterprise organization which increases the limits for job concurrency and usable monthly minutes.

Some ASWF projects have their own top-level GitHub organization: these are included under our Enterprise account and should have the same access as projects / repos under the AcademySofftwareFoundation GitHub organization.

ASWF also has a limited monthly budget for Larger Runners which add runners to support larger numbers of CPU, more RAM, different CPU architectures and GPUs. These Larger Runners are managed by Linux Foundation Release Engineering team and can be selected by the runs-on  directive in the workflow file. They can only be used by CI jobs running in the context of the project repository, they cannot be accessed from a fork.

Since the monthly budget is limited, projects should make judicious use of these Larger Runners, possibly for lower frequency jobs to validate different CPU architectures, or to run a GPU-accelerated test suite rather than a full compilation. Projects wishing to use these Larger Runners may want to bring up their requirements for discussion in the #wg-ci Slack channel.

Per minute pricing is listed under Per-minute rates for x64-powered larger runners and Per-minute rates for arm64-powered larger runners. These charges add up fast, especially for matrixed builds. Keep in mind that:

• Windows runners are 2x the cost of Linux runners

• 4 core GPU runners cost the same as 16 core CPU only runners

For projects needing access to GPUs, you would typically want to build on a CPU only runner, upload build artifacts “somewhere”, and then only run the GPU-dependent test suite on a GPU runner.

Users with commit access to a repository can show the larger runners available to the repo under Actions → Runners → Github-hosted runners :

Open

As of July 2024, the following Larger Runners are available. Additional configurations can be discussed in the #wg-ci Slack channel and requested via a Linux Foundation help desk ticket:

• 4 core x86_64 / 16GB / 150GB disk

  • ubuntu-latest-m 

• 4 core x86_64 / 16GB / 176GB disk NVIDIA Tesla T4 GPU

  • ubuntu-20.04-gpu-t4-4c-16g-176h 

  • windows-ds-2019-gpu-t4-4c-16g-176h 

• 8 core x86_64 / 32GB / 300GB disk

  • ubuntu-20.04-8c-32g-300h 

  • ubuntu-22.04-8c-32g-300h

  • ubuntu-latest-8c-32g-300h

  • windows-2022-8c-32g-300h

  • windows-latest-l 

• 16 core x86_64 / 64GB /  600GB disk

  • ubuntu-20.04-16c-64g-600h 

  • ubuntu-22.04-16c-64g-600h

  • ubuntu-latest-16c-64g-600h

  • windows-2022-16c-64g-600h 

• 2 core arm64 / 8GB / 75GB disk

  • ubuntu-24.04-arm64-2C-8G-75H 

  • ubuntu-24.04-arm64-2C-8G-75H 

• 4 core arm64 / 16GB / 150GB disk

  • ubuntu-22.04-arm64-4C-16G-150H 

  • ubuntu-24.04-arm64-4C-16G-150H

  • windows-11-arm64-4C-16G-150H 

•  8 core arm64 / 32GB / 300GB disk

  • ubuntu-22.04-arm64-8C-32G-300H 

  • ubuntu-24.04-arm64-8C-32G-300H 

  • windows-11-arm64-8C-32G-300H 

• 16 core arm64 / 64GB / 600GB disk

  • ubuntu-22.04-arm64-16C-64G-600H 

  • ubuntu-24.04-arm64-16C-64G-600H 

  • windows-11-arm64-16C-64G-600H 

Issue with GitHub Actions and CentOS 7 based aswf-docker containers

The GitHub Actions runner is based on Node.js, and in the transition from Node 16 to 20, uses a build of Node linked against libc 2.27. This will prevent CI builds using aswf-docker containers based on the VFX Reference Platform 2022 or older from running:

This issue is discussed here: https://github.com/actions/runner/issues/2906

A previous workaround using environment variables to force the use of Node 16 no longer works as of December 2024. Instead, it is possible to overlay the Node 20 build used by the checkout action with a glibc 2.27 build downloaded from builds.nodejs.org:

PR against OpenImageIO demonstrating how the fix can be implemented: https://github.com/AcademySoftwareFoundation/OpenImageIO/pull/4543

The “NodeJS unofficials build” project has recently (summer 2026) restored glibc 2.17 builds, for instance you can now find a build of NodeJS 24 for CentOS 7 / glibc 2.17.

GPU larger runner images and NVIDIA driver versions

GPU equipped Larger Runners use a "Partner Image" called NVIDIA GPU-Optimized VMI:

That VMI is documented here:

https://marketplace.microsoft.com/en-us/product/nvidia.ngc_azure_17_11

which points to here:

https://docs.nvidia.com/ngc/ngc-deploy-public-cloud/ngc-azure/index.html#azure-vmi

As of 2026-09-02 that NVIDIA documentation is somewhat out of date: it shows the most recent version 24.10.1 as being based on Ubuntu 22.04 and having NVIDIA driver 550.127.05, but a GHA job poking around shows that the image has been updated to Ubuntu 24.04 and driver 590.48.01.

The CUDA toolkit compatibility matrix is here:

https://docs.nvidia.com/cuda/cuda-toolkit-release-notes/index.html#cuda-major-component-versions__table-cuda-toolkit-driver-versions

and shows that with driver 590.48.01 you can run CUDA up to 13.1.1, you need 610.43.02 or newer for 13.3.0 / 13.3.1.

You can create custom images for larger runners:

so in theory we could start with the NVIDIA GPU-Optimized VMI, upgrade the NVIDIA driver to R610, generate an updated image, and create a new GPU larger runner which references this custom image. Some drawbacks of this approach:

• you need some (preferably non public) GHA code to generate the custom image, that would need to be maintained by LF RelEng

• you no longer get "automatic" updates from the Partner Image

• the configurator for larger runners is tricky, it's not a given that it will let you specify a GPU instance with anything but a partner image

• there's a (likely small) ongoing storage cost for partner images

Another potential approach is to forego the convenience of being able to just specify:

and run inside a GPU-enabled container, and instead first update the NVIDIA driver on the runner VM, then manually run each step of a build with docker run ... but I don't think that's very attractive.

So it makes sense for aswf-docker images to stick to a CUDA version which is supported by the NVIDIA driver version currently in the NVIDIA GPU-Optimized VMI partner image used by the ubuntu-20.04-gpu-t4-4c-16g-176h image. Note that the naming of this larger runner is a bit misleading:

• 16g refers to the VRAM size on the T4 GPU, the runner itself has 28GB of RAM

• ubuntu-20.04 was correct at the time the larger runner was added to the AcademySoftwareFoundation GitHub organization, but the partner image is currently (Sept 2026) based on Ubuntu 24.04.1.