Create or update GTSAM CI Docker images in borglab/docker-images. Use when adding a new Ubuntu/compiler image such as ubuntu-26.04-gcc-15, updating gtsam-ci Dockerfiles, testing image tags used by GTSAM GitHub Actions, or guiding a maintainer through building and publishing GTSAM CI images to Docker Hub.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
A direct command skips the review prompt. Inspect the source before running it.
Create or update GTSAM CI Docker images in borglab/docker-images. Use when adding a new Ubuntu/compiler image such as ubuntu-26.04-gcc-15, updating gtsam-ci Dockerfiles, testing image tags used by GTSAM GitHub Actions, or guiding a maintainer through building and publishing GTSAM CI images to Docker Hub.
GTSAM CI Image
Scope
Work from the docker-images repository, especially gtsam-ci/. The GTSAM repository consumes these images from GitHub Actions as:
If the maintainer wants to publish only the new tag, ask for confirmation first, then guide them through:
docker login
docker push borglab/gtsam-ci:<tag>
After the maintainer confirms the image has been pushed or built by Docker Hub, include optional local cleanup commands for any tags built during validation:
If a new base image was also built, include its tag in the same docker image rm command. Note that docker buildx prune -f removes unused BuildKit cache beyond this one image family and can make future local Docker rebuilds slower.
gtsam-ci/build_and_push.sh borglab builds and pushes every image in gtsam-ci/; mention that broader blast radius before recommending it.
Validation
Use references/release-checklist.md when preparing the maintainer-facing upload instructions. Use scripts/smoke_test_image.sh for local validation when Docker is available.
When Docker is unavailable or the image cannot be built locally, say that explicitly and provide the exact commands the maintainer should run.
Never assume a tag exists on Docker Hub just because a Dockerfile exists locally. Verify by pulling it or treat publication as a required maintainer step.
