Build and Testing
Relevant source files
This document covers the automated build system, continuous integration pipeline, testing procedures, and documentation generation for the AxVM hypervisor project. It explains the multi-architecture build matrix, CI/CD workflow stages, and quality assurance processes that ensure code reliability across supported platforms.
For information about development dependencies and integration with the ArceOS ecosystem, see Dependencies and Integration.
Build System Overview
The AxVM project uses a GitHub Actions-based continuous integration system that validates code quality, builds across multiple architectures, and generates documentation. The build system supports three primary target architectures (x86_64, RISC-V, and AArch64) with different execution environments ranging from hosted Linux to bare-metal embedded targets.
CI Pipeline Architecture
flowchart TD
subgraph subGraph3["Documentation Pipeline"]
doc_build["cargo doc --no-deps"]
index_redirect["index.html redirect"]
gh_pages_deploy["GitHub Pages deploy"]
end
subgraph subGraph2["Build Stages"]
format_check["cargo fmt --check"]
clippy_lint["cargo clippy"]
cargo_build["cargo build"]
unit_tests["cargo test"]
end
subgraph subGraph1["CI Job Matrix"]
matrix_strategy["strategy.matrix"]
toolchain_variants["rust-toolchain variants"]
target_variants["targets variants"]
nightly_2024["nightly-2024-12-25"]
nightly_latest["nightly"]
x86_linux["x86_64-unknown-linux-gnu"]
x86_none["x86_64-unknown-none"]
riscv_none["riscv64gc-unknown-none-elf"]
aarch64_none["aarch64-unknown-none-softfloat"]
end
subgraph subGraph0["GitHub Actions Workflow"]
trigger["push/pull_request triggers"]
ci_job["ci job"]
doc_job["doc job"]
end
cargo_build --> unit_tests
ci_job --> format_check
ci_job --> matrix_strategy
clippy_lint --> cargo_build
doc_build --> index_redirect
doc_job --> doc_build
format_check --> clippy_lint
index_redirect --> gh_pages_deploy
matrix_strategy --> target_variants
matrix_strategy --> toolchain_variants
target_variants --> aarch64_none
target_variants --> riscv_none
target_variants --> x86_linux
target_variants --> x86_none
toolchain_variants --> nightly_2024
toolchain_variants --> nightly_latest
trigger --> ci_job
trigger --> doc_job
Sources: .github/workflows/ci.yml(L1 - L61)
Supported Architecture Targets
The build system validates AxVM across multiple target architectures that align with the hypervisor's multi-architecture support design. Each target represents a different execution environment and use case.
| Target Triple | Architecture | Environment | Use Case |
|---|---|---|---|
| x86_64-unknown-linux-gnu | x86_64 | Hosted Linux | Development, unit testing |
| x86_64-unknown-none | x86_64 | Bare metal | Hypervisor deployment |
| riscv64gc-unknown-none-elf | RISC-V 64-bit | Bare metal ELF | RISC-V hypervisor |
| aarch64-unknown-none-softfloat | AArch64 | Bare metal, soft FP | ARM hypervisor |
Build Matrix Configuration
flowchart TD
subgraph Components["Components"]
rust_src["rust-src"]
clippy_comp["clippy"]
rustfmt_comp["rustfmt"]
end
subgraph subGraph1["Target Matrix"]
x86_linux["x86_64-unknown-linux-gnu"]
x86_bare["x86_64-unknown-none"]
riscv_bare["riscv64gc-unknown-none-elf"]
arm_bare["aarch64-unknown-none-softfloat"]
end
subgraph subGraph0["Toolchain Matrix"]
stable_toolchain["nightly-2024-12-25"]
latest_toolchain["nightly"]
end
latest_toolchain --> arm_bare
latest_toolchain --> riscv_bare
latest_toolchain --> x86_bare
latest_toolchain --> x86_linux
stable_toolchain --> arm_bare
stable_toolchain --> clippy_comp
stable_toolchain --> riscv_bare
stable_toolchain --> rust_src
stable_toolchain --> rustfmt_comp
stable_toolchain --> x86_bare
stable_toolchain --> x86_linux
Sources: .github/workflows/ci.yml(L10 - L19)
CI Pipeline Stages
The continuous integration pipeline consists of multiple validation stages that run sequentially for each target in the build matrix. The pipeline uses a fail-fast: false strategy to ensure all combinations are tested even if some fail.
Code Quality Validation
The first stage validates code formatting and style consistency:
sequenceDiagram
participant GitHubActions as "GitHub Actions"
participant RustToolchain as "Rust Toolchain"
participant cargofmt as "cargo fmt"
participant cargoclippy as "cargo clippy"
GitHubActions ->> RustToolchain: "Setup nightly toolchain"
GitHubActions ->> RustToolchain: "Install components: rust-src, clippy, rustfmt"
GitHubActions ->> RustToolchain: "Add target: ${{ matrix.targets }}"
GitHubActions ->> cargofmt: "cargo fmt --all -- --check"
cargofmt ->> GitHubActions: "Format validation result"
GitHubActions ->> cargoclippy: "cargo clippy --target ${{ matrix.targets }} --all-features"
Note over cargoclippy: "Allows clippy::new_without_default"
cargoclippy ->> GitHubActions: "Lint validation result"
The clippy stage includes specific configuration to suppress the new_without_default warning, allowing constructors without Default implementation.
Sources: .github/workflows/ci.yml(L22 - L26)
Build Validation
Each target architecture undergoes compilation validation with full feature enablement:
cargo build --target ${{ matrix.targets }} --all-features
The build stage uses continue-on-error for the latest nightly toolchain to prevent pipeline failures from upstream Rust changes while maintaining stability with the pinned nightly version.
Sources: .github/workflows/ci.yml(L27 - L29)
Unit Testing
Unit tests execute only on the x86_64-unknown-linux-gnu target, which provides the hosted environment necessary for test execution:
cargo test --target x86_64-unknown-linux-gnu -- --nocapture
This restriction reflects the practical limitation that bare-metal targets cannot execute standard Rust test harnesses without additional infrastructure.
Sources: .github/workflows/ci.yml(L30 - L33)
Documentation Generation
The documentation pipeline operates independently from the main CI job and includes automated deployment to GitHub Pages for the default branch.
Documentation Build Process
flowchart TD
subgraph subGraph2["Deployment Conditions"]
default_branch_check["github.ref == default-branch"]
single_commit["single-commit: true"]
target_folder["folder: target/doc"]
end
subgraph subGraph1["RUSTDOCFLAGS Environment"]
broken_links["-D rustdoc::broken_intra_doc_links"]
missing_docs["-D missing-docs"]
end
subgraph subGraph0["Documentation Job"]
doc_trigger["GitHub trigger"]
doc_checkout["Checkout repository"]
doc_toolchain["Setup nightly-2024-12-25"]
doc_build["cargo doc --no-deps --all-features"]
doc_index["Generate index.html redirect"]
doc_deploy["Deploy to gh-pages branch"]
end
broken_links --> doc_build
default_branch_check --> doc_deploy
doc_build --> doc_index
doc_checkout --> doc_toolchain
doc_index --> doc_deploy
doc_toolchain --> doc_build
doc_trigger --> doc_checkout
missing_docs --> doc_build
single_commit --> doc_deploy
target_folder --> doc_deploy
The documentation build enforces strict documentation standards through RUSTDOCFLAGS that treat broken intra-doc links and missing documentation as compilation errors.
Sources: .github/workflows/ci.yml(L35 - L61)
Index Page Generation
The pipeline automatically generates a redirect index page that points to the main crate documentation:
printf '<meta http-equiv="refresh" content="0;url=%s/index.html">' $(cargo tree | head -1 | cut -d' ' -f1) > target/doc/index.html
This command extracts the crate name from cargo tree output and creates an HTML redirect to the appropriate documentation entry point.
Sources: .github/workflows/ci.yml(L52 - L53)
Error Handling and Resilience
The CI configuration includes several resilience mechanisms to handle different failure scenarios:
| Condition | Behavior | Purpose |
|---|---|---|
| continue-on-error: ${{ matrix.rust-toolchain == 'nightly' }} | Allow latest nightly failures | Prevent upstream breakage |
| fail-fast: false | Continue other matrix jobs on failure | Complete validation coverage |
| Documentation error handling | Allow non-default branch doc failures | Prevent blocking on doc issues |
The pipeline distinguishes between the stable nightly toolchain (nightly-2024-12-25) and the latest nightly, allowing experimentation with newer compiler versions while maintaining build stability.
Sources: .github/workflows/ci.yml(L8 - L9) .github/workflows/ci.yml(L25) .github/workflows/ci.yml(L28) .github/workflows/ci.yml(L32) .github/workflows/ci.yml(L50)
Quality Assurance Standards
The CI pipeline enforces several quality standards across the codebase:
- Code Formatting: Uniform formatting via
rustfmtwith--checkflag - Linting: Comprehensive linting through
clippywith minimal suppressions - Documentation: Complete documentation coverage with broken link detection
- Multi-architecture Compatibility: Build validation across all supported targets
- Feature Completeness: All builds use
--all-featuresto ensure complete validation
These standards ensure that AxVM maintains high code quality and reliability across its supported platforms and use cases.
Sources: .github/workflows/ci.yml(L22 - L33) .github/workflows/ci.yml(L43) .github/workflows/ci.yml(L49 - L53)