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.
./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>