CH-TEST(1)

📦
version 0.44 · 10 versions
, in ubuntu stonking

💖 CH-TEST(1) — Charliecloud edition 💖

okay bestie, sit down, hydrate, because this is the manual page for ch-test, a.k.a. the little script that runs Charliecloud's whole test suite. she's the group-chat organizer of your containers. let's go 🦋

✨ NAME ✨

ch-test — run some or all of the Charliecloud test suite

✨ SYNOPSIS ✨

$ ch-test [PHASE] [--scope SCOPE] [--pack-fmt FMT] [ARGS]

✨ DESCRIPTION ✨

Charliecloud ships with a whole comprehensive test suite — like, it exercises the container workflow itself plus a few example applications. And ch-test is the girl coordinating all of it. 💅

The CLI has a lot of options, but listen: the defaults are reasonable. literally just bare ch-test will give you useful results in a few minutes on single-node, internet-connected systems that have a few GB free in /var/tmp. no cap.

The test suite needs a few GB (standard scope) or tens of GB (full scope) of storage for test fixtures:

  • Builder storage (e.g. layer cache). This goes wherever the builder puts it.
  • Packed images directory: image tarballs or SquashFS files.
  • Unpacked images directory. Images get unpacked into here and then run from here.
  • Filesystem permissions directories. These are used to test that the kernel is enforcing permissions correctly. heads up: this exercises the kernel, not Charliecloud, and can totally be omitted from routine Charliecloud testing.

The first three get created when needed if they don't exist, while the filesystem permissions fixtures must be created manually — that's on purpose, so we can accommodate configurations where sudo isn't available via the same login path used for running tests.

🚨 the packed and unpacked image directories you specify for testing are volatile. Their contents are deleted before the build and run phases, respectively. gone. poof. 💀

In all four cases, when creating directories, only the final path component is created. Parent directories must already exist — i.e. ch-test uses the behavior of mkdir rather than mkdir -p. iykyk.

Some of the tests exercise parallel functionality. If ch-test is run on a single node, multiple cores will be used; if in a Slurm allocation, multiple nodes too. she multi-tasks. 👑

The subset of tests to run mostly splits along two key dimensions. The phase is which parts of the workflow to run. Different parts of the workflow can be tested on different systems by copying the necessary artifacts between them, e.g. by building images on one system and running them on another. The scope allows trading off thoroughness versus time.

🎀 PHASE 🎀

PHASE must be one of the following:

  • build — image building and associated functionality, with the selected builder.
  • run — running containers and associated functionality. This requires a packed images directory produced by a successful build phase, which can be copied from the build system if it's not also the run system.
  • rootemu — test the root emulation modes (seccomp, fakeroot, and none) on various linux distributions.
  • examples — example applications. Requires an unpacked images directory produced by a successful run phase.
  • all — execute phases build, rootemu, run, and examples, in that order.
  • mk-perm-dirs — create the filesystem permissions directories. Requires --perm-dirs.
  • build-images — build images from build phase, without running the associated tests.
  • clean — delete automatically-generated test files, and packed and unpacked image directories.
  • rm-perm-dirs — remove the filesystem permissions directories. Requires --perm-dirs.
  • *-f, --file *FILE[:TEST]** — run the tests in the given file only, which can be an arbitrary .batsfile, except fortest.bats` under examples, where you must specify the corresponding Dockerfile or Build file instead. This is somewhat brittle and typically used for development or debugging. For example, it does not check whether the pre-requisites of whatever is in the file are satisfied. Often running build and run first is sufficient, but this varies.

If TEST is also given, then run only tests with name containing that string, skipping the others. The separator is a literal colon. If the string contains shell metacharacters such as space, you'll need to quote the argument to protect it from the shell.

🙈 yes bestie, -f/--file is technically an option, not a phase, but the manpage lists it right here in this block so we're keeping it right here. fidelity first, periodt.

🔍 Scope 🔍

Scope is specified with:

  • -s, --scope SCOPE — SCOPE must be one of the following:
    • quick: most important subset of workflow. Handy for development.
    • standard: all tested workflow functionality and a selection of more important examples. (Default.)
    • full: all available tests, including all examples.

🖼️ Image format 🖼️

Image format is specified with:

  • --pack-fmt FMT — FMT must be one of the following:
    • squash-mount or 🐘: SquashFS archive, run directly from the archive using ch-run's internal SquashFUSE functionality. In this mode, tests that require writing to the image are skipped.
    • tar-unpack or 📠: tarball, and the images are unpacked before running.
    • squash-unpack or 🎃: SquashFS, and the images are unpacked before running.

Default: $CH_TEST_PACK_FMT if set. Otherwise, if mksquashfs(1) is available and ch-run was built with libsquashfuse support, then squash-mount, else tar-unpack.

🧚 Additional arguments 🧚

  • -b, --builder BUILDER — image builder to use. Default: $CH_TEST_BUILDER if set, otherwise ch-image.
  • --dry-run — print summary of what would be tested and then exit.
  • -h, --help — print usage and then exit.
  • --img-dir DIR — set unpacked images directory to DIR. In a multi-node allocation, this directory may not be shared between nodes. Default: $CH_TEST_IMGDIR if set; otherwise /var/tmp/${USER}.img.
  • --lustre DIR — use DIR for run-phase Lustre tests. Default: CH_TEST_LUSTREDIR if set; otherwise skip them.

The tests will create, populate, and delete a new subdirectory under DIR, leaving everything else in DIR untouched. (respectful queens 🌸)

  • --pack-dir DIR — set packed images directory to DIR. Default: $CH_TEST_TARDIR if set; otherwise /var/tmp/${USER}.pack.
  • --pedantic (yes|no) — some tests require configurations that are very specific (e.g., being a member of at least two groups) or unusual (e.g., sudo to a non-root group). If yes, then fail if the requirement is not met; if no, then skip. The default is yes for CI environments or people listed in README.md, no otherwise.

If yes and sudo seems to be available, implies --sudo.

  • --perm-dir DIR — add DIR to filesystem permission fixture directories; can be specified multiple times. We recommend one such directory per mounted filesystem type whose kernel module you do not trust; e.g., you probably don't need to test your tmpfses, but out-of-tree filesystems very likely need this.

Implies --sudo. Default: CH_TEST_PERMDIRS if set; otherwise skip the filesystem permissions tests.

  • --sudo — enable things that require sudo, such as certain privilege escalation tests and creating/removing the filesystem permissions fixtures. Requires generic sudo capabilities. Note that the Docker builder uses sudo docker even without this option. (she said what she said 💅)

✨ EXIT STATUS ✨

Zero if all tests passed; non-zero if any failed. For setup and teardown phases, zero if everything was created or deleted correctly, non-zero otherwise.

✨ BUGS ✨

Bats will wait until all descendant processes finish before exiting, so if you get into a failure mode where a test sequence doesn't clean up all its processes, ch-test will hang. 😭 not a vibe. consider this your warning.

✨ EXAMPLES ✨

Many systems can simply use the defaults. To run the build, run, and examples phases on a single system, without the filesystem permissions tests:

$ ch-test
ch-test version 0.12

ch-run: 0.12 /usr/local/bin/ch-run
bats:   0.4.0 /usr/bin/bats
tests:  /usr/local/libexec/charliecloud/test

phase:                build run examples
scope:                standard (default)
builder:              docker (default)
use generic sudo:     no (default)
unpacked images dir:  /var/tmp/img (default)
packed images dir:    /var/tmp/tar (default)
fs permissions dirs:  skip (default)

checking namespaces ...
ok

checking builder ...
found: /usr/bin/docker 19.03.2

bats build.bats build_auto.bats build_post.bats
 ✓ documentation seems sane
 ✓ version number seems sane
[...]
All tests passed.

The next example is for a more complex setup like you might find in HPC centers:

  • Non-default fixture directories.
  • Non-default scope.
  • Different build and run systems.
  • Run the filesystem permissions tests.

Output has been omitted.

(mybox)$ ssh hpc-admin
(hpc-admin)$ ch-test mk-perm-dirs --perm-dir /scratch/$USER/perms \
                                  --perm-dir /home/$USER/perms
(hpc-admin)$ exit
(mybox)$ ch-test build --scope full
(mybox)$ scp -r /var/tmp/pack hpc:/scratch/$USER/pack
(mybox)$ ssh hpc
(hpc)$ salloc -N2
(cn001)$ export CH_TEST_TARDIR=/scratch/$USER/pack
(cn001)$ export CH_TEST_IMGDIR=/local/tmp
(cn001)$ export CH_TEST_PERMDIRS="/scratch/$USER/perms /home/$USER/perms"
(cn001)$ export CH_TEST_SCOPE=full
(cn001)$ ch-test run
(cn001)$ ch-test examples

✨ REPORTING BUGS ✨

If Charliecloud was obtained from your Linux distribution, use your distribution's bug reporting procedures.

Otherwise, report bugs to: <https://github.com/hpc/charliecloud/issues>

✨ SEE ALSO ✨

charliecloud(7)

Full documentation at: <<https://hpc.github.io/charliecloud>>

contributors to the Charliecloud project, which has been established as “Charliecloud a Series of LF Projects, LLC”. For web site terms of use, trademark policy, and related information, please see: https://lfprojects.org.

and that's the whole page, bestie 🫶 this one's from 0.44, dated 2026-05-31 07:53 UTC. go run some tests, you're gonna slay 💖✨🎀

📦 where this page comes from