CI/CD Pipelines

Loading…

CI/CD Pipelines

Relevant source files

• .cargo/config.toml.example
• .github/dependabot.yml
• .github/workflows/build-docs.yml
• .github/workflows/python-direct-release.yml.TODO
• .github/workflows/python-net-release.yml
• .github/workflows/rust-lint.yml
• .github/workflows/rust-release.yml
• .github/workflows/rust-tests.yml
• .gitignore

This page describes the GitHub Actions workflows and automated pipelines that ensure the stability, security, and delivery of the rust-simd-r-drive ecosystem. The CI/CD infrastructure covers Rust core testing across multiple platforms, Python binding builds, security auditing, and automated releases to GitHub and PyPI.

Core Rust Workflows

The Rust CI infrastructure is split into validation (linting/security) and functional testing (matrix builds).

Rust Linting and Security

The rust-lint.yml workflow performs static analysis and security checks on every pull request [ .github/workflows/rust-lint.yml3](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-lint.yml#L3-L3) It ensures that the codebase adheres to formatting standards, passes Clippy’s suggestions, and is free from known vulnerabilities in dependencies.

Sources: [ .github/workflows/rust-lint.yml1-50](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-lint.yml#L1-L50)

Multi-Platform Testing Matrix

The rust-tests.yml workflow executes the test suite across a matrix of Operating Systems and Cargo feature flags to ensure compatibility and performance stability. It includes a specific check to ensure benchmarks compile via cargo bench --workspace --no-run [ .github/workflows/rust-tests.yml65-66](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-tests.yml#L65-L66)

Data Flow: Test Matrix Execution The diagram below illustrates how the matrix strategy expands into individual job executions.

Sources: [ .github/workflows/rust-tests.yml1-67](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-tests.yml#L1-L67)

graph TD
    subgraph "Matrix_Strategy"
        OS["OS: [ubuntu-latest, macos-latest, windows-latest]"]
FEAT["Features: [Default, No-Default, Parallel, Expose-API, Parallel+Expose, All]"]
end

 
   OS --> JOB["Job: Test (OS, Features)"]
FEAT --> JOB

 
   JOB --> CHECKOUT["actions/checkout@v4"]
CHECKOUT --> RUST["dtolnay/rust-toolchain@stable"]
RUST --> CACHE["actions/cache@v4 (Cargo deps & target/)"]
CACHE --> BUILD["cargo build --workspace --all-targets"]
BUILD --> TEST["cargo test --workspace --all-targets --verbose"]
TEST --> BENCH["cargo bench --workspace --no-run"]
style JOB stroke-width:2px

Python and Network Pipelines

The project maintains specialized pipelines for building and testing Python bindings, specifically the WebSocket-based client.

Python WebSocket Integration

The python-net-release.yml manages the lifecycle of integration tests where a Rust WebSocket server is spawned to serve a Python client.

1. Environment Setup : Uses uv to manage Python dependencies and setup-python for the interpreter [ .github/workflows/python-net-release.yml31-39](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L31-L39)
2. Test Execution : Runs integration_test.sh, which handles starting the simd-r-drive-ws-server, running Python tests, and tearing down the server [ .github/workflows/python-net-release.yml42-45](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L42-L45)

Python Release Pipeline

The python-net-release.yml workflow builds platform-specific wheels using cibuildwheel and publishes them to PyPI. A similar TODO workflow exists for the direct (legacy) bindings [ .github/workflows/python-direct-release.yml.TODO1-104](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-direct-release.yml.TODO#L1-L104)

• Wheel Building : Uses cibuildwheel (version 2.23.3) to compile the Rust extensions for modern Python versions [ .github/workflows/python-net-release.yml48-56](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L48-L56)
• Targeting : Specifically skips older Python versions and 32-bit architectures (e.g., cp36, manylinux_i686) to focus on modern 64-bit systems [ .github/workflows/python-net-release.yml54](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L54-L54)
• Publishing Logic : Distinguishes between test releases (tags containing -test) and production releases to target either test.pypi.org or upload.pypi.org [ .github/workflows/python-net-release.yml88-101](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L88-L101)

Sources: [ .github/workflows/python-net-release.yml1-102](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-net-release.yml#L1-L102) [ .github/workflows/python-direct-release.yml.TODO1-104](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/python-direct-release.yml.TODO#L1-L104)

Automated Release and Documentation

Rust Binary Releases

The rust-release.yml workflow automates the creation of GitHub Releases. It compiles the simd-r-drive CLI in --release mode for Linux, macOS, and Windows [ .github/workflows/rust-release.yml16-26](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-release.yml#L16-L26) It renames the binaries for clarity (e.g., adding .exe for Windows) [ .github/workflows/rust-release.yml28-37](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-release.yml#L28-L37) and uploads them as release assets when a version tag (e.g., v*) is pushed [ .github/workflows/rust-release.yml49-64](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-release.yml#L49-L64)

Sources: [ .github/workflows/rust-release.yml1-65](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-release.yml#L1-L65)

Documentation Deployment

The build-docs.yml workflow generates this wiki as a searchable mdBook and deploys it to GitHub Pages. It runs on a weekly schedule or manually via workflow_dispatch [ .github/workflows/build-docs.yml4-7](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/build-docs.yml#L4-L7)

Entity Mapping: Documentation Pipeline This diagram maps the documentation build process to the tools and outputs used in the workflow.

Sources: [ .github/workflows/build-docs.yml1-81](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/build-docs.yml#L1-L81)

graph LR
    subgraph "Input_Space"
        REPO["GitHub Repository Content"]
CRON["Schedule: Weekly (Sunday)"]
end

    subgraph "Code_Entity_Space"
        DW["jzombie/deepwiki-to-mdbook@main"]
MD["mdBook Engine"]
OUT["./output/book"]
end

 
   REPO --> DW
 
   CRON --> DW
 
   DW --> MD
 
   MD --> OUT
 
   OUT --> PAGES["GitHub Pages Deployment"]
style DW stroke-dasharray: 5 5

Dependency Management

The project uses GitHub Dependabot to maintain up-to-date and secure dependencies.

• Ecosystem : Monitored for the cargo package manager [ .github/dependabot.yml8](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/dependabot.yml#L8-L8)
• Schedule : Checks for updates on a weekly basis [ .github/dependabot.yml11](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/dependabot.yml#L11-L11)
• Configuration : Scans the root directory for Cargo.toml manifests [ .github/dependabot.yml9](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/dependabot.yml#L9-L9)

Sources: [ .github/dependabot.yml1-12](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/dependabot.yml#L1-L12)

Build Environment Configuration

The repository includes a .cargo/config.toml.example which is used to redirect crate dependencies to local paths during development, particularly for the rust-muxio suite [ .cargo/config.toml.example1-6](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .cargo/config.toml.example#L1-L6) CI environments typically rely on the standard crates.io versions unless these overrides are active.

Code Entity Mapping: CI Validation Flow The CI environment relies on specific cargo commands to validate the workspace. The following diagram shows how the CI jobs map to the actual cargo commands executed in the environment.

graph TD
    subgraph "Natural_Language_Space"
        LINT["Linting & Security"]
TESTING["Multi-Platform Tests"]
end

    subgraph "Code_Entity_Space"
        CLIPPY["cargo clippy --workspace"]
AUDIT["cargo audit"]
DENY["cargo deny check"]
T_WORK["cargo test --workspace"]
B_WORK["cargo bench --no-run"]
end

 
   LINT --> CLIPPY
 
   LINT --> AUDIT
 
   LINT --> DENY
 
   TESTING --> T_WORK
 
   TESTING --> B_WORK

    style CLIPPY stroke-width:2px
    style T_WORK stroke-width:2px

Sources: [ .github/workflows/rust-lint.yml37-49](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-lint.yml#L37-L49) [ .github/workflows/rust-tests.yml59-66](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .github/workflows/rust-tests.yml#L59-L66) [ .cargo/config.toml.example1-6](https://github.com/jzombie/rust-simd-r-drive/blob/5652ca4d/ .cargo/config.toml.example#L1-L6)