Docker container specifications which package dependencies for building Khronos documentation and software.

Images built from this github repository are pushed to the Dockerhub repository https://hub.docker.com/r/khronosgroup/docker-images.

Each Dockerfile is named <tag>.Dockerfile where <tag> (e.g. openxr, asciidoctor-spec) matches the tag for that image in the Dockerhub repository (e.g. KhronosGroup/docker-images:rust). A second tag is suffixed with .<date> representing a timestamp when this image was last modified.

In general, any additional arguments are forwarded on to docker build except the first if it is "push", so this is how you can pass --no-cache to force a rebuild, etc.

• Single-image scripts: pass a tag name as the first argument and a version as the second.
  • ./build-one.sh <tag> <date> - Just builds and tags the image locally, does not push to Dockerhub. Use for testing modifications.
  • ./build-one.sh <tag> <date> push - Builds and tags the image locally, then pushes it to Dockerhub. Only run this once you've committed (and ideally, pushed) the corresponding changes to this Git repo.
• ./build-all.sh - Just calls ./build-one.sh on all the tags listed in it. Use as ./build-all.sh push to push all images to Dockerhub. If you add a new Dockerfile to this repo, add it to this script too.

We have encountered problems with both gitlab and Github Actions CI not flushing cache when an updated image of the same name is pushed to dockerhub. While using different tags on every push is a possibility, another approach is to use the container SHA256 hash instead of the container name. This is printed out at the end of a build, or can be determined as follows:

$ docker inspect --format='{{index .RepoDigests 0}}' khronosgroup/docker-images:asciidoctor-spec
khronosgroup/docker-images@sha256:1535246a0270e5a118b11ba121ac3c08849782d27afcac28e3859424db659f2f

Using the last line as the image name in CI will pull that specific hash instead of whatever the currently cached version of the underlying image name is. This works in both gitlab and Github Actions.

Docker builds can consume many GB of storage very quickly, and old containers and images you are no longer using can do so as well. You can get an idea how much is used via

docker system df

See https://depot.dev/blog/docker-clear-cache for suggestions on cleaning up after builds. In particular, these commands are often useful:

# Clean the build cache
docker buildx prune

# List images, including their IDs
docker image ls -a --digests

# Remove specific images; adding '--force' may be useful if there are
# persistent images and you no longer know what they're associated with.
docker image rmi <ID>