You cannot select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

History

Andrew Werner 15b3c459ae xtask: ensure libbpf submodule is initialized Libbpf is used by xtasks, in the command, ensure that the submodules are initialized. This eases the user-experience so that users don't need to think about the submodule, while retaining all the benefits of using a submodule vs forcing the user to manually check out libbpf and stick it in some pre-defined place. We use the symbol pointing to libbpf in xtask in the build script to avoid repeating this constant. Also, we install git in the vm so that we can init the submodule when we build in the vm.		1 year ago
..
integration-ebpf	Add integration test for perf link pin	1 year ago
integration-test	xtask: ensure libbpf submodule is initialized	1 year ago
.gitignore	test: Replace RTF with Rust	2 years ago
README.md	integration-test: compile Rust probes using build.rs	1 year ago
cloud-localds	integration-tests: run on macos to get nested virtualization	2 years ago
run.sh	xtask: ensure libbpf submodule is initialized	1 year ago

Aya Integration Tests

The aya integration test suite is a set of tests to ensure that common usage behaviours work on real Linux distros

Prerequisites

To run locally all you need is:

A POSIX shell
A checkout of libbpf
rustup target add x86_64-unknown-linux-musl
cargo install bpf-linker
Install qemu and cloud-init-utils package - or any package that provides cloud-localds

From the root of this repository:

cargo xtask integration-test

./test/run.sh

Tests should follow these guidelines:

Rust eBPF code should live in integration-ebpf/${NAME}.rs and included in integration-ebpf/Cargo.toml and integration-test/src/lib.rs using include_bytes_aligned!.
C eBPF code should live in integration-test/bpf/${NAME}.bpf.c. It should be added to the list of files in integration-test/build.rs and the list of constants in integration-test/src/lib.rs using include_bytes_aligned!.
Tests should be added to integration-test/tests.
You may add a new module, or use an existing one.
Test functions should not return anyhow::Result<()> since this produces errors without stack traces. Prefer to panic! instead.