This is meant to make the project more searchable on the Internet. More and more people have been pointing out that "toolbox" is terribly difficult to search for, and it's impossible to find any decent Internet real estate by that name. Some exceptions: * The code repository is still https://github.com/containers/toolbox. It will be renamed after giving a heads-up to other contributors. * The name of the binary is still 'toolbox'. The name is embedded into existing Toolbx containers as their entry point, which is bind mounted from the host operating system when the containers are started. Trivially renaming the binary will prevent these containers from starting. * For similar reasons, the TOOLBOX_PATH environment variable is still the same. * For similar reasons, the profile.d file to be read by the shell on start-up is still called toolbox.sh. * The label used to identify Toolbx containers and images is still called com.github.containers.toolbox. There are many existing Toolbx containers, and many Toolbx images beyond the control of the Toolbx project that use this label to identity themselves. Simply renaming the label will prevent these containers and images from being recognized. * The names of the built-in Toolbx images still retain the word 'toolbox'. Images under the new name need to be published on the OCI registries and the toolbox(1) binary needs to be taught to handle both old and new names, wherever necessary, for backwards compatibility. * The stamp file used to identify Toolbx containers is still called /run/.toolboxenv because it's used by various external programs and users to identify Toolbx containers. * The OSC 777 escape sequence to track and preserve the user's current Toolbx container [1] still emits 'toolbox' as the name of the container runtime. Changing the escape sequence can break terminal emulation applications, like Prompt [2], that consume it. Hence, it needs to be done carefully. * The runtime directories at /run/toolbox, when used as root, and $XDG_RUNTIME_DIR/toolbox, when used rootless, weren't renamed. When used as root, /run/toolbox is embedded into existing Toolbx containers as a bind mount from the host. Trivially renaming the path will prevent these containers from starting. Secondly, both these paths are used to synchronize container start-up. If the paths are trivially renamed, and the toolbox(1) binary is updated and used without stopping all existing containers, then it won't be able to enter containers that were already started. Strictly speaking, this scenario isn't supported, since updates are always expected to be "offline" [3]. However, it's worth noting because solving the previous problem might also address this. * The configuration file for RPM is still called /usr/lib/rpm/macros.d/macros.toolbox. [1] https://gitlab.freedesktop.org/terminal-wg/specifications/-/issues/17 [2] https://gitlab.gnome.org/chergert/prompt [3] https://www.freedesktop.org/software/systemd/man/latest/systemd.offline-updates.html https://github.com/containers/toolbox/issues/1399 |
||
|---|---|---|
| .. | ||
| libs | ||
| 001-version.bats | ||
| 002-help.bats | ||
| 101-create.bats | ||
| 102-list.bats | ||
| 103-container.bats | ||
| 104-run.bats | ||
| 105-enter.bats | ||
| 106-rm.bats | ||
| 107-rmi.bats | ||
| 108-completion.bats | ||
| 201-ipc.bats | ||
| 203-network.bats | ||
| 206-user.bats | ||
| 210-ulimit.bats | ||
| 211-dbus.bats | ||
| 220-environment-variables.bats | ||
| README.md | ||
| meson.build | ||
| setup_suite.bash | ||
README.md
System tests
These tests are built with BATS (Bash Automated Testing System).
The tests are meant to ensure that Toolbx's functionality remains stable throughout updates of both Toolbx and Podman/libpod.
The tests are set up in a way that does not affect the host environment. Running them won't remove any existing containers or images.
Dependencies
awkbatsGNU coreutilshttpd-toolsopensslpodmanskopeotoolbox
These tests use a few standard libraries for bats which help with clarity
and consistency. The libraries are bats-support
and bats-assert. These libraries are
provided as git submodules in the libs directory. Make sure both are present
by running git submodule init and git submodule update.
How to run the tests
First, make sure you have all the dependencies installed.
- Enter the toolbox root folder
- Invoke command
bats ./test/system/and the test suite should fire up
Mocking of images is done automatically to prevent potential networking issues and to speed up the cases.
By default the test suite uses the system versions of podman, skopeo and
toolbox.
If you have a podman, skopeo or toolbox installed in a nonstandard
location then you can use the PODMAN, SKOPEO and TOOLBX environmental
variables to set the path to the binaries. So the command to invoke the test
suite could look something like this: PODMAN=/usr/libexec/podman TOOLBX=./toolbox bats ./test/system/.
When running the tests, make sure the test suite: [job] jobs are successful.
These jobs set up the whole environment and are a strict requirement for other
jobs to run correctly.
Writing tests
Environmental variables
- Inspect top part of
libs/helpers.batsfor a list of helper environmental variables
Naming convention
- All tests should follow the nomenclature:
[command]: <test description>... - When the test is expected to fail, start the test description with "Try to..."
- When the test is to give a non obvious output, it should be put in parenthesis at the end of the title
Examples:
@test "create: Create the default container"@test "rm: Try to remove a non-existent container"
Test case environment
- All the tests start with a clean system (no images or containers) to make sure
that there are no dependencies between tests and they are really isolated. Use
the
setup()andteardown()functions for that purpose.
Image registry
-
The system tests set up an OCI image registry for testing purposes -
localhost:50000. The registry requires authentication. There is one account present:user(password:user) -
The registry contains by default only one image:
fedora-toolbox:34
Example pull of the fedora-toolbox:34 image:
$PODMAN login --username user --password user "$DOCKER_REG_URI"
$PODMAN pull "$DOCKER_REG_URI/fedora-toolbox:34"