1a1b956201
When 'toolbox run ulimit' is invoked, it comes down to invoking
"bash --login -c 'exec ulimit'" inside the container, and it leads to
different outcomes on Fedora and Ubuntu hosts.
On Fedora:
$ bash --login -c 'exec ulimit'
unlimited
On Ubuntu:
$ bash --login -c 'exec ulimit'
bash: line 1: exec: ulimit: not found
This is because Bash's exec built-in cannot execute another built-in and
needs an external command; and Fedora ships a wrapper for the ulimit
built-in as an external command [1] to satisfy POSIX [2]:
$ cat /usr/bin/ulimit
#!/usr/bin/sh
builtin ulimit "$@"
... that Ubuntu doesn't.
Wrapping the 'ulimit' as 'bash -c ulimit' solves this problem because
then it becomes "bash --login -c 'exec bash -c ulimit'", and the exec
built-in can execute the external command bash(1).
[1] Fedora bash commit 3b09d0d67fe7ff4c
Fedora bash commit a28ab9933095eaf6
https://src.fedoraproject.org/rpms/bash/c/3b09d0d67fe7ff4c
https://src.fedoraproject.org/rpms/bash/c/a28ab9933095eaf6
https://bugzilla.redhat.com/show_bug.cgi?id=1297166
[2] http://pubs.opengroup.org/onlinepubs/9699919799/utilities/toc.html
https://github.com/containers/toolbox/pull/1599
Signed-off-by: Penn Bauman <me@pennbauman.com>
|
||
|---|---|---|
| .. | ||
| data | ||
| 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 | ||
| 230-cdi.bats | ||
| 250-kerberos.bats | ||
| 270-rpm.bats | ||
| 501-create.bats | ||
| 504-run.bats | ||
| 505-enter.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 toolbox installed in a nonstandard location then you can use the
TOOLBX environmental variable to set the path to the binary. So the command
to invoke the test suite could look something like this:
TOOLBX=./toolbox bats ./test/system/.
It's recommended to set the TMPDIR
environment variable to /var/tmp when running the tests. Otherwise, the
images downloaded during the tests will be cached in /tmp, which is
typically on tmpfs backed by RAM or swap and should be used for smaller
size-bounded files only.
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"