Docker Images for the Academy Software Foundation
Changes are documented in CHANGELOG.md
These images are for Continuous Integration testing of various project managed by the ASWF.
Each image (apart from
ci-common) is available for multiple VFX Platform Years.
|aswf/ci-common:1||A base CentOS-7 image with devtoolset-6 (GCC-6.3.1), clang-7 and cuda-10.2.|
|aswf/ci-common:2||A base CentOS-7 image with devtoolset-9.1 (GCC-9.3.1), clang-10 and cuda-11.|
ASWF_VFXPLATFORM_VERSION is the calendar year mentioned in the
VFX Platform, e.g.
ASWF_VERSION is a semantic version made of the
as the major version number, and a minor version number to indicate minor
changes in the Docker Image that still point to the same calendar year version,
2019.0 would be followed if necessary by a
The minor version here does not point to a calendar month or quarter, it is
solely to express that the image has changed internally. We could also have a
The most precise version tag is the
ASWF_VERSION of the image, e.g.
aswf/ci-base:2019.0, but it is recommended to use the
ASWF_VFXPLATFORM_VERSION as the tag to use in CI pipelines, e.g.
latest tag is pointing to the current VFX Platform year images, e.g.
aswf/ci-openexr:latest points to
aswf/ci-openexr:2019.0 but will be
updated to point to
aswf/ci-openexr:2020.0 in the calendar year 2020.
There is another Docker Hub organization with copies of the
aswftesting, images published there are for general testing and
experimentation. Images can be pushed by any fork of the official repo as long
as the branch is called
testing. Images in this org will change without
notice and could be broken in many unexpected ways!
To get write access to the
aswftesting Docker Hub organization you can open
a Jira issue there.
As of November 2021 there are full 2018, 2019, 2020, 2021 and 2022 VFX Platform compliant images. N.B. that the 2018 version of the images still exist but are not maintained/rebuilt anymore, which means they might be obsolete (especially the OS part).
In order to decouple the building of packages (which can take a lot of time, such as clang, Qt and USD) from the management of the CI Images, the packages are built and stored into "scratch" Docker images that can be "copied" into the CI images at image build time by Docker.
Storing these CI packages into Docker images has the additional benefit of
being completely free to store on the Docker Hub repository.
The main negative point about this way of storing build artifacts is that
tarballs are not available directly to download. It is very trivial to generate
one and the provided
download-package.sh script can be used to generate a
local tarball from any package.
Also, CI packages are built using experimental Docker syntax that allows cache
folders to be mounted at build time, and is built with
docker buildx. The new
Docker BuildKit system allows the building of many packages in parallel in an
efficient way with support for ccache.
Check aswfdocker for python utility usage.
To build packages and images locally follow the instructions to install the aswfdocker python utility.
Packages require a recent Docker version with buildx installed and enabled.
To build all packages (very unlikely to succeed unless run on a very very powerful machine!):
aswfdocker --verbose build -t PACKAGE
To build a single package, e.g. USD:
# First list the available CI packages to know which package belong to which "group": aswfdocker packages # Then run the build aswfdocker --verbose build -t PACKAGE --group vfx --version 2019 --target usd # Or the simpler but less flexible syntax: aswfdocker build -n aswftesting/ci-package-usd:2019
Images can be built with recent Docker versions but do not require buildx but it is recommended to speed up large builds.
To build all images (very unlikely to succeed unless run on a very very powerful machine!):
aswfdocker --verbose build -t IMAGE
To build a single image:
# First list the available CI images to know which package belong to which "group": aswfdocker images # Then run the build aswfdocker --verbose build -t IMAGE --group vfx1 --version 2019 --target openexr # Or the simpler but less flexible syntax: aswfdocker build -n aswftesting/ci-openexr:2019