apparmor/spread.yaml

250 lines
10 KiB
YAML
Raw Normal View History

Allow running tests with spread Spread is a full-system, or integration test suite runner initially developed to test snapd. Over time it has spread to other projects where it provides a structured way to organize, run and debug complex full-system interactions. Spread is documented on https://github.com/canonical/spread and is used in production since late 2016. Spread has a notion of backends which are responsible for allocating and discarding test machines. For the purpose of running AppArmor regression tests, I've combined spread with my own tool, image garden. The tool provides off-the-shelf images, constructed on-the-fly from freely available images, and makes them easily available to spread. The reason for doing it this way is so that using non-free cloud systems is not required and anyone can repeat the test process locally, on their own computer. Vanilla spread is somewhat limited to x86-64 systems but the way I've used it here makes it equally possible to test x86_64 *and* aarch64 systems. I've done most of the development on an ARM single-board-computer running on my desk. Spread requires a top-level spread.yaml file and a collection of task.yaml files that describe individual tasks (for us, those are just tests). Tasks have no implied dependency except that to reach a given task, spread will run all the _prepare_ statements leading to that task, starting from the project, test suite and then task. With proper care one can then run a specific individual test with a one-line command, for example: ``` spread -v garden:ubuntu-cloud-24.04:tests/regression/apparmor:at_secure ``` This will prepare a fresh ubuntu-cloud-24.04 system (matching the CPU architecture of the host), copy the project tree into the test machine, install all the build dependencies, build all the parts of apparmor and then run one specific variant of the regression test, namely the at_secure program. Importantly the same test can also run on, say debian-cloud-13 (Debian Trixie), but also, if you have a Google cloud account, on Google Compute Engine or in one of the other backends either built into spread or available as a fork of spread or as a helper for ad-hoc backend. Spread can also create more than one worker per system and distribute the tests to all of the available instances. In no way are we locking ourselves out of the ability to run our test suite on our target of choice. Spread has other useful switches, such as: - `-reuse` for keeping machines around until discarded with -discard - `-resend` for re-sending updated copy of the project (useful for -reuse) - `-debug` for starting an interactive shell on any failure - `-shell` for starting an interactive shell instead of the `execute` phase This first patch contains just the spread elements, assuming that both spread and image-garden are externally installed. A GitLab continuous integration installing everything required and running a subset of tests will follow shortly. I've expanded the initial selection of systems to allow running all the tests on several versions of Ubuntu, Debian and openSUSE, mainly as a sanity check but also to showcase how practical spread is at covering real-world systems. A number of systems and tests are currently failing: - garden:debian-cloud-12:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-12:tests/regression/apparmor:deleted - garden:debian-cloud-12:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-12:tests/regression/apparmor:unix_socket_pathname - garden:debian-cloud-13:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-13:tests/regression/apparmor:deleted - garden:debian-cloud-13:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-13:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-15.6:tests/regression/apparmor:deleted - garden:opensuse-cloud-15.6:tests/regression/apparmor:e2e - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:xattrs_profile - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:deleted - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_socket_pathname - garden:ubuntu-cloud-22.04:tests/regression/apparmor:attach_disconnected In addition, only on openSUSE, I've skipped the entire test suite of the utils directory, as it requires python3 ttk themes, which I cannot find in packaged form. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit cc041815786c6a1f4c3bd95f3d70386767e94852) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-25 13:54:03 +01:00
project: apparmor
backends:
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
garden:
# The garden backend relies on https://gitlab.com/zygoon/image-garden
# TODO: Switch to a released version for better stability.
type: adhoc
allocate: |
# Use just enough RAM to link the parser on a virtual system with
# two cores. Using more cores may easily consume more memory, due
# to make -j$(nproc), used below than a small CI/CD system is
# typically granted. It is better to have more workers than to
# have one big worker with lots of resources.
export QEMU_MEM_OPTION="-m 1536"
export QEMU_SMP_OPTION="-smp 2"
ARCH="$(uname -m)"
# If a locally built kernel image exist then use it for booting.
# Care needs to be taken to make sure the kernel is compatible with
# loadable modules present in the file system.
if [ -f bzImage ]; then
# Create the qcow2/run files before setting custom kernel
# options, so that first boot and initialization happen in a
# standardized manner.
image-garden make "$SPREAD_SYSTEM"."$ARCH".run "$SPREAD_SYSTEM"."$ARCH".qcow2 1>&2
# Pass a simple drive instead of the more elaborate virtio
# configuration that is used by default. Some images may not
# support virtio enough for booting.
export QEMU_STORAGE_OPTION="-drive file=$SPREAD_SYSTEM.$ARCH.qcow2,format=qcow2"
# Refrain from passing EFI firmware to qemu so that we boot a
# kernel directly and bypass both EFI and BIOS.
export QEMU_BOOT_FIRMWARE_OPTION=""
# Pass the kernel and cmdline by hand. At present this is tuned
# to the Ubuntu cloud images that have the rootfs as the first
# partition.
exec image-garden allocate "$SPREAD_SYSTEM"."$ARCH" \
-kernel bzImage \
-append 'root=/dev/sda1 ro console=tty1 console=ttyS0'
fi
# Ask image garden to allocate the system and relay the result back
# to spread as either success of failure.
exec image-garden allocate "$SPREAD_SYSTEM"."$ARCH"
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
discard: image-garden discard "$SPREAD_SYSTEM_ADDRESS"
systems:
# All systems except for the one Ubuntu system are marked as
# manual. This way we don't accidentally spin up everything when
# someone runs spread without knowing better.
- opensuse-cloud-tumbleweed:
username: opensuse
password: opensuse
workers: 4
manual: true
- debian-cloud-12:
username: debian
password: debian
workers: 4
manual: true
- debian-cloud-13:
username: debian
password: debian
workers: 4
manual: true
- ubuntu-cloud-22.04:
username: ubuntu
password: ubuntu
workers: 4
manual: true
- ubuntu-cloud-24.04:
username: ubuntu
password: ubuntu
workers: 4
manual: true
- ubuntu-cloud-24.10:
username: ubuntu
password: ubuntu
workers: 4
- fedora-cloud-41:
username: fedora
password: fedora
Allow running tests with spread Spread is a full-system, or integration test suite runner initially developed to test snapd. Over time it has spread to other projects where it provides a structured way to organize, run and debug complex full-system interactions. Spread is documented on https://github.com/canonical/spread and is used in production since late 2016. Spread has a notion of backends which are responsible for allocating and discarding test machines. For the purpose of running AppArmor regression tests, I've combined spread with my own tool, image garden. The tool provides off-the-shelf images, constructed on-the-fly from freely available images, and makes them easily available to spread. The reason for doing it this way is so that using non-free cloud systems is not required and anyone can repeat the test process locally, on their own computer. Vanilla spread is somewhat limited to x86-64 systems but the way I've used it here makes it equally possible to test x86_64 *and* aarch64 systems. I've done most of the development on an ARM single-board-computer running on my desk. Spread requires a top-level spread.yaml file and a collection of task.yaml files that describe individual tasks (for us, those are just tests). Tasks have no implied dependency except that to reach a given task, spread will run all the _prepare_ statements leading to that task, starting from the project, test suite and then task. With proper care one can then run a specific individual test with a one-line command, for example: ``` spread -v garden:ubuntu-cloud-24.04:tests/regression/apparmor:at_secure ``` This will prepare a fresh ubuntu-cloud-24.04 system (matching the CPU architecture of the host), copy the project tree into the test machine, install all the build dependencies, build all the parts of apparmor and then run one specific variant of the regression test, namely the at_secure program. Importantly the same test can also run on, say debian-cloud-13 (Debian Trixie), but also, if you have a Google cloud account, on Google Compute Engine or in one of the other backends either built into spread or available as a fork of spread or as a helper for ad-hoc backend. Spread can also create more than one worker per system and distribute the tests to all of the available instances. In no way are we locking ourselves out of the ability to run our test suite on our target of choice. Spread has other useful switches, such as: - `-reuse` for keeping machines around until discarded with -discard - `-resend` for re-sending updated copy of the project (useful for -reuse) - `-debug` for starting an interactive shell on any failure - `-shell` for starting an interactive shell instead of the `execute` phase This first patch contains just the spread elements, assuming that both spread and image-garden are externally installed. A GitLab continuous integration installing everything required and running a subset of tests will follow shortly. I've expanded the initial selection of systems to allow running all the tests on several versions of Ubuntu, Debian and openSUSE, mainly as a sanity check but also to showcase how practical spread is at covering real-world systems. A number of systems and tests are currently failing: - garden:debian-cloud-12:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-12:tests/regression/apparmor:deleted - garden:debian-cloud-12:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-12:tests/regression/apparmor:unix_socket_pathname - garden:debian-cloud-13:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-13:tests/regression/apparmor:deleted - garden:debian-cloud-13:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-13:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-15.6:tests/regression/apparmor:deleted - garden:opensuse-cloud-15.6:tests/regression/apparmor:e2e - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:xattrs_profile - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:deleted - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_socket_pathname - garden:ubuntu-cloud-22.04:tests/regression/apparmor:attach_disconnected In addition, only on openSUSE, I've skipped the entire test suite of the utils directory, as it requires python3 ttk themes, which I cannot find in packaged form. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit cc041815786c6a1f4c3bd95f3d70386767e94852) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-25 13:54:03 +01:00
exclude:
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
- .git
- "*.o"
# Files related to spread and image-garden.
- "*.qcow2"
- "*.iso"
- "*.img"
- "*.log"
- "*.run"
- "*.lock"
- spread-logs
- spread-artifacts
# Locally provided kernel image. See allocate section in system backends,
# this image, if present, is passed directly to qemu.
- bzImage
Allow running tests with spread Spread is a full-system, or integration test suite runner initially developed to test snapd. Over time it has spread to other projects where it provides a structured way to organize, run and debug complex full-system interactions. Spread is documented on https://github.com/canonical/spread and is used in production since late 2016. Spread has a notion of backends which are responsible for allocating and discarding test machines. For the purpose of running AppArmor regression tests, I've combined spread with my own tool, image garden. The tool provides off-the-shelf images, constructed on-the-fly from freely available images, and makes them easily available to spread. The reason for doing it this way is so that using non-free cloud systems is not required and anyone can repeat the test process locally, on their own computer. Vanilla spread is somewhat limited to x86-64 systems but the way I've used it here makes it equally possible to test x86_64 *and* aarch64 systems. I've done most of the development on an ARM single-board-computer running on my desk. Spread requires a top-level spread.yaml file and a collection of task.yaml files that describe individual tasks (for us, those are just tests). Tasks have no implied dependency except that to reach a given task, spread will run all the _prepare_ statements leading to that task, starting from the project, test suite and then task. With proper care one can then run a specific individual test with a one-line command, for example: ``` spread -v garden:ubuntu-cloud-24.04:tests/regression/apparmor:at_secure ``` This will prepare a fresh ubuntu-cloud-24.04 system (matching the CPU architecture of the host), copy the project tree into the test machine, install all the build dependencies, build all the parts of apparmor and then run one specific variant of the regression test, namely the at_secure program. Importantly the same test can also run on, say debian-cloud-13 (Debian Trixie), but also, if you have a Google cloud account, on Google Compute Engine or in one of the other backends either built into spread or available as a fork of spread or as a helper for ad-hoc backend. Spread can also create more than one worker per system and distribute the tests to all of the available instances. In no way are we locking ourselves out of the ability to run our test suite on our target of choice. Spread has other useful switches, such as: - `-reuse` for keeping machines around until discarded with -discard - `-resend` for re-sending updated copy of the project (useful for -reuse) - `-debug` for starting an interactive shell on any failure - `-shell` for starting an interactive shell instead of the `execute` phase This first patch contains just the spread elements, assuming that both spread and image-garden are externally installed. A GitLab continuous integration installing everything required and running a subset of tests will follow shortly. I've expanded the initial selection of systems to allow running all the tests on several versions of Ubuntu, Debian and openSUSE, mainly as a sanity check but also to showcase how practical spread is at covering real-world systems. A number of systems and tests are currently failing: - garden:debian-cloud-12:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-12:tests/regression/apparmor:deleted - garden:debian-cloud-12:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-12:tests/regression/apparmor:unix_socket_pathname - garden:debian-cloud-13:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-13:tests/regression/apparmor:deleted - garden:debian-cloud-13:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-13:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-15.6:tests/regression/apparmor:deleted - garden:opensuse-cloud-15.6:tests/regression/apparmor:e2e - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:xattrs_profile - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:deleted - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_socket_pathname - garden:ubuntu-cloud-22.04:tests/regression/apparmor:attach_disconnected In addition, only on openSUSE, I've skipped the entire test suite of the utils directory, as it requires python3 ttk themes, which I cannot find in packaged form. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit cc041815786c6a1f4c3bd95f3d70386767e94852) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-25 13:54:03 +01:00
# Copy the project to this path on the test system.
# This is also available as $SPREAD_PATH.
path: /tmp/apparmor
prepare: |
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
# Configure libapparmor but only if a makefile is not already present.
# This makes repeated iteration with -reuse much faster, as the chain of
# invocations of make below are efficient if nothing needs to be done.
if [ ! -f "$SPREAD_PATH"/libraries/libapparmor/Makefile ]; then
(
cd $SPREAD_PATH/libraries/libapparmor
sh ./autogen.sh && sh ./configure --prefix=/usr --with-perl --with-python
)
fi
# Build libapparmor.
make -C $SPREAD_PATH/libraries/libapparmor -j"$(nproc)"
# Build apparmor_parser.
make -C $SPREAD_PATH/parser -j"$(nproc)"
# Build binary utilities (aa-exec and firends).
make -C $SPREAD_PATH/binutils -j"$(nproc)"
# Build python utilities.
make -C $SPREAD_PATH/utils -j"$(nproc)"
# Build apache and pam modules.
make -C "$SPREAD_PATH"/changehat/mod_apparmor -j"$(nproc)"
make -C "$SPREAD_PATH"/changehat/pam_apparmor -j"$(nproc)"
Allow running tests with spread Spread is a full-system, or integration test suite runner initially developed to test snapd. Over time it has spread to other projects where it provides a structured way to organize, run and debug complex full-system interactions. Spread is documented on https://github.com/canonical/spread and is used in production since late 2016. Spread has a notion of backends which are responsible for allocating and discarding test machines. For the purpose of running AppArmor regression tests, I've combined spread with my own tool, image garden. The tool provides off-the-shelf images, constructed on-the-fly from freely available images, and makes them easily available to spread. The reason for doing it this way is so that using non-free cloud systems is not required and anyone can repeat the test process locally, on their own computer. Vanilla spread is somewhat limited to x86-64 systems but the way I've used it here makes it equally possible to test x86_64 *and* aarch64 systems. I've done most of the development on an ARM single-board-computer running on my desk. Spread requires a top-level spread.yaml file and a collection of task.yaml files that describe individual tasks (for us, those are just tests). Tasks have no implied dependency except that to reach a given task, spread will run all the _prepare_ statements leading to that task, starting from the project, test suite and then task. With proper care one can then run a specific individual test with a one-line command, for example: ``` spread -v garden:ubuntu-cloud-24.04:tests/regression/apparmor:at_secure ``` This will prepare a fresh ubuntu-cloud-24.04 system (matching the CPU architecture of the host), copy the project tree into the test machine, install all the build dependencies, build all the parts of apparmor and then run one specific variant of the regression test, namely the at_secure program. Importantly the same test can also run on, say debian-cloud-13 (Debian Trixie), but also, if you have a Google cloud account, on Google Compute Engine or in one of the other backends either built into spread or available as a fork of spread or as a helper for ad-hoc backend. Spread can also create more than one worker per system and distribute the tests to all of the available instances. In no way are we locking ourselves out of the ability to run our test suite on our target of choice. Spread has other useful switches, such as: - `-reuse` for keeping machines around until discarded with -discard - `-resend` for re-sending updated copy of the project (useful for -reuse) - `-debug` for starting an interactive shell on any failure - `-shell` for starting an interactive shell instead of the `execute` phase This first patch contains just the spread elements, assuming that both spread and image-garden are externally installed. A GitLab continuous integration installing everything required and running a subset of tests will follow shortly. I've expanded the initial selection of systems to allow running all the tests on several versions of Ubuntu, Debian and openSUSE, mainly as a sanity check but also to showcase how practical spread is at covering real-world systems. A number of systems and tests are currently failing: - garden:debian-cloud-12:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-12:tests/regression/apparmor:deleted - garden:debian-cloud-12:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-12:tests/regression/apparmor:unix_socket_pathname - garden:debian-cloud-13:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-13:tests/regression/apparmor:deleted - garden:debian-cloud-13:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-13:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-15.6:tests/regression/apparmor:deleted - garden:opensuse-cloud-15.6:tests/regression/apparmor:e2e - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:xattrs_profile - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:deleted - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_socket_pathname - garden:ubuntu-cloud-22.04:tests/regression/apparmor:attach_disconnected In addition, only on openSUSE, I've skipped the entire test suite of the utils directory, as it requires python3 ttk themes, which I cannot find in packaged form. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit cc041815786c6a1f4c3bd95f3d70386767e94852) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-25 13:54:03 +01:00
# In case of failure, include the kernel version in the log.
debug-each: |
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
uname -a
Allow running tests with spread Spread is a full-system, or integration test suite runner initially developed to test snapd. Over time it has spread to other projects where it provides a structured way to organize, run and debug complex full-system interactions. Spread is documented on https://github.com/canonical/spread and is used in production since late 2016. Spread has a notion of backends which are responsible for allocating and discarding test machines. For the purpose of running AppArmor regression tests, I've combined spread with my own tool, image garden. The tool provides off-the-shelf images, constructed on-the-fly from freely available images, and makes them easily available to spread. The reason for doing it this way is so that using non-free cloud systems is not required and anyone can repeat the test process locally, on their own computer. Vanilla spread is somewhat limited to x86-64 systems but the way I've used it here makes it equally possible to test x86_64 *and* aarch64 systems. I've done most of the development on an ARM single-board-computer running on my desk. Spread requires a top-level spread.yaml file and a collection of task.yaml files that describe individual tasks (for us, those are just tests). Tasks have no implied dependency except that to reach a given task, spread will run all the _prepare_ statements leading to that task, starting from the project, test suite and then task. With proper care one can then run a specific individual test with a one-line command, for example: ``` spread -v garden:ubuntu-cloud-24.04:tests/regression/apparmor:at_secure ``` This will prepare a fresh ubuntu-cloud-24.04 system (matching the CPU architecture of the host), copy the project tree into the test machine, install all the build dependencies, build all the parts of apparmor and then run one specific variant of the regression test, namely the at_secure program. Importantly the same test can also run on, say debian-cloud-13 (Debian Trixie), but also, if you have a Google cloud account, on Google Compute Engine or in one of the other backends either built into spread or available as a fork of spread or as a helper for ad-hoc backend. Spread can also create more than one worker per system and distribute the tests to all of the available instances. In no way are we locking ourselves out of the ability to run our test suite on our target of choice. Spread has other useful switches, such as: - `-reuse` for keeping machines around until discarded with -discard - `-resend` for re-sending updated copy of the project (useful for -reuse) - `-debug` for starting an interactive shell on any failure - `-shell` for starting an interactive shell instead of the `execute` phase This first patch contains just the spread elements, assuming that both spread and image-garden are externally installed. A GitLab continuous integration installing everything required and running a subset of tests will follow shortly. I've expanded the initial selection of systems to allow running all the tests on several versions of Ubuntu, Debian and openSUSE, mainly as a sanity check but also to showcase how practical spread is at covering real-world systems. A number of systems and tests are currently failing: - garden:debian-cloud-12:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-12:tests/regression/apparmor:deleted - garden:debian-cloud-12:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-12:tests/regression/apparmor:unix_socket_pathname - garden:debian-cloud-13:tests/regression/apparmor:attach_disconnected - garden:debian-cloud-13:tests/regression/apparmor:deleted - garden:debian-cloud-13:tests/regression/apparmor:unix_fd_server - garden:debian-cloud-13:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-15.6:tests/regression/apparmor:deleted - garden:opensuse-cloud-15.6:tests/regression/apparmor:e2e - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-15.6:tests/regression/apparmor:unix_socket_pathname - garden:opensuse-cloud-15.6:tests/regression/apparmor:xattrs_profile - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:attach_disconnected - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:deleted - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_fd_server - garden:opensuse-cloud-tumbleweed:tests/regression/apparmor:unix_socket_pathname - garden:ubuntu-cloud-22.04:tests/regression/apparmor:attach_disconnected In addition, only on openSUSE, I've skipped the entire test suite of the utils directory, as it requires python3 ttk themes, which I cannot find in packaged form. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit cc041815786c6a1f4c3bd95f3d70386767e94852) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-25 13:54:03 +01:00
suites:
tests/profiles/:
summary: Tests that exercise specific application profiles
# variables:
# PROFILE_NAME: name of the profile on disk
# PROGRAM_NAME: name of the program to execute
prepare-each: |
rm -f denials.txt
# Disable rate-limiting so that we see all denials.
sysctl --values kernel.printk_ratelimit >old-ratelimit.txt
sysctl --write kernel.printk_ratelimit=0
# Stop auditd so that all denials end up in the ring buffer.
if [ "$(systemctl is-active auditd.service)" != inactive ]; then
systemctl stop auditd.service
touch did-stop-auditd.txt
fi
# Clear the kernel ring buffer.
dmesg --clear
# Compute profile name from the name of the task.
echo "PROFILE_NAME=${PROFILE_NAME:=$(basename "$SPREAD_TASK")}"
"$SPREAD_PATH"/parser/apparmor_parser \
--warn=all \
--replace \
--skip-cache \
--base="$SPREAD_PATH"/profiles/apparmor.d \
"$SPREAD_PATH"/profiles/apparmor.d/"$PROFILE_NAME" 2>parser.txt
if [ -s parser.txt ]; then
echo "Parser produced warnings:"
cat parser.txt
exit 1
fi
restore-each: |
# Compute profile name from the name of the task.
echo "PROFILE_NAME=${PROFILE_NAME:=$(basename "$SPREAD_TASK")}"
"$SPREAD_PATH"/parser/apparmor_parser \
--base="$SPREAD_PATH"/profiles/apparmor.d \
--remove \
"$SPREAD_PATH"/profiles/apparmor.d/"$PROFILE_NAME"
# Restore auditd and old rate-limit.
if [ -f did-stop-auditd.txt ]; then
systemctl start auditd.service
rm -f did-stop-auditd.txt
fi
if [ -f old-ratelimit.txt ]; then
sysctl -w kernel.printk_ratelimit="$(cat old-ratelimit.txt)"
rm -f old-ratelimit.txt
fi
# Check if running the test resulted in any logged denials.
if dmesg | grep DENIED > denials.txt; then
echo "Denials were emitted during the test"
cat denials.txt
exit 1
fi
debug-each: |
echo "PROGRAM_NAME=${PROGRAM_NAME:=$(basename "$SPREAD_TASK")}"
command -v "$PROGRAM_NAME"
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
utils/:
summary: Unit tests for the Python utilities.
prepare: |
# Generate apparmor profiles that the tests rely on.
make -C "$SPREAD_PATH"/parser/tst gen_xtrans gen_dbus
# Spread does not support programmatically generated test variants.
# Ensure that the list baked into utils/test/task.yaml contains all
# the files matching utils/test/test-*.py
fail=0
for V in $SPREAD_PATH/utils/test/test-*.py; do
Vdash="$(basename "$V" | sed -e 's,^test-,,' -e 's,\.py$,,')"
Vunder="$(basename "$V" | sed -e 's,^test-,,' -e 's,\.py$,,' -e 's,-,_,g')"
if ! grep -xF ' TEST/'"$Vunder"': '"$Vdash" "$SPREAD_PATH"/utils/test/task.yaml; then
echo "utils/test/task.yaml: missing test variant: TEST/$Vunder: $Vdash" >&2
fail=1
fi
done
if [ "$fail" -ne 0 ]; then
echo "exiting due to missing variants listed above" >&2
exit 1
fi
tests/unit/:
summary: Unit tests that do not exercise the kernel layer.
tests/regression/:
summary: Regression tests for parser-kernel interaction.
systems:
# AppArmor is not enabled in the kernel.
- -fedora-cloud-*
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
prepare: |
# Spread does not support programmatically generated test variants.
# Ensure that the list baked into tests/regression/apparmor/task.yaml
# contains all the tests defined in tests/regression/apparmor/Makefile.
echo '$(foreach t,$(TESTS),$(info TEST/$t))' | \
make -n -f "$SPREAD_PATH"/tests/regression/apparmor/Makefile -f /dev/stdin | \
grep -F TEST/ | \
cut -d / -f 2 | \
tee apparmor-regression-tests.txt
fail=0
while read -r V; do
if ! grep -xF ' TEST/'"$V"': 1' "$SPREAD_PATH"/tests/regression/apparmor/task.yaml; then
echo "tests/regression/task.yaml: missing test variant: TEST/$V" >&2
fail=1
fi
done <apparmor-regression-tests.txt
if [ "$fail" -ne 0 ]; then
echo "exiting due to missing variants listed above" >&2
exit 1
fi
Second iteration of spread support Compared to v1 the following improvements have been made: - The cost of installing packages have been shifted from each startup to image preparation phase, thanks to the integration of custom cloud-init profiles into image-garden. This has dramatic impact on iteration time while also entirely removing requirement to be online to run once a prepared image is available. - Support for running on Google Compute Engine has been removed since it would not be able to use cloud-init the same way would currently only complicate setup. - The number of workers have been tuned for local iteration, aiming for comfortable work with 16GB of memory on the host. Once CI/CD pipeline support is introduced I will add a dedicated entry so that resources are utilized well both locally and when running in CI. - The set of regression tests listed in tests/regression/apparmor/task.yaml is now cross-checked so introduction of a new test to the makefile there is automatically flagged and causes spread to fail with a clear message. - The task tests/unit/utils has been improved to generate profiles. Thanks to Christian Boltz for explaining this relationship between tests. - A number of comments have been improved and cleaned up for readability, accuracy and sometimes better grammar. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit c95ac4d3500eec3f5713c1eebda28f72177d785e) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 01:15:51 +01:00
Third iteration of spread support - Tests defined in utils/test are now described by a task.yaml in the same directory and can run concurrently across many machines. - Tests for utils/ are now executed on openSUSE Tumbleweed since ttk themes is no longer a hard dependency in master. - Tests no longer run on openSUSE Leap 15.6 due to the age of default Python (3.6) and gcc/g++. The tight integration with SWIG which does not seem to support other Python versions very well. Perl hard-codes old GCC for extension modules. The upcoming openSUSE Leap 16 should be a viable target. In the meantime we can still test everything through rolling-release Tumbleweed. - Formatting of YAML files is now more uniform, at four spaces per tab. - The run-spread.sh script is now in the root of the tree. The script allows running all spread tests sequentially on one system, while collecting logs and artifacts for convenient analysis after the fact. - All systems are adjusted to run _four_ workers in parallel with _two_ virtual cores each and equipped with 1.5GB of virtual memory. This aims to best utilize the capacity of a typical CI worker with two to four cores and about 8GB of available memory. - Failing tests are marked as such, so that as a whole the entire spread suite can pass and be useful at catching regressions. Signed-off-by: Zygmunt Krynicki <zygmunt.krynicki@canonical.com> (cherry picked from commit 1df91e2c8c936a887f34b5bd2d3afcb682b7c72c) Signed-off-by: John Johansen <john.johansen@canonical.com>
2024-11-26 15:40:19 +01:00
# Build all the apparmor regression test programs.
make -C "$SPREAD_PATH"/tests/regression/apparmor -j"$(nproc)"
restore: |
rm -f apparmor-regression-tests.txt
tests/snapd/:
summary: Tests exercising a subset of behavior of snapd
systems:
# AppArmor is not enabled in the kernel.
- -fedora-cloud-*