This document describes the GitHub Actions-based continuous integration and deployment infrastructure for fuel-core. The pipeline handles code verification (linting, formatting, testing), release publishing (crates and binaries), and Docker image builds. For information about the testing framework itself, see Testing Framework. For Docker deployment configuration, see Docker Images and Deployment. For Kubernetes deployment workflows, see Kubernetes Deployment.
The CI/CD system consists of four primary workflows:
cargo updateAll workflows use GitHub Actions with BuildJet runners for improved performance. The system enforces strict quality gates before merging and automates the entire release process from tag creation to artifact distribution.
Sources: .github/workflows/ci.yml1-467 .github/workflows/docker-images.yml1-414
CI Job Dependency Graph
The workflow implements a strict dependency chain with parallel execution where possible. Initial checks (check-changelog, rustfmt, lint-toml-files, prevent-openssl) must pass before verification jobs begin. The cargo-verifications matrix and specialized tests run in parallel, all feeding into verifications-complete gate. Release jobs only execute when a GitHub release is published and all verifications pass.
Sources: .github/workflows/ci.yml32-279
The CI workflow defines standardized environment variables used across all jobs:
| Variable | Value | Purpose |
|---|---|---|
RUST_VERSION | 1.90.0 | Stable toolchain for builds |
RUST_VERSION_FMT | nightly-2025-09-28 | Nightly for rustfmt |
RUST_VERSION_COV | nightly-2025-09-28 | Nightly for coverage |
RUSTFLAGS | -D warnings | Treat warnings as errors |
CARGO_TERM_COLOR | always | Enable color output |
REGISTRY | ghcr.io | GitHub Container Registry |
AWS_ROLE_ARN | arn:aws:iam::024848458133:role/... | OIDC role for ECR |
The workflow uses concurrency groups to cancel redundant runs:
This prevents multiple CI runs for rapid pushes to the same PR or branch.
Sources: .github/workflows/ci.yml17-30 .github/workflows/ci.yml13-15
The check-changelog job ensures every PR includes a changelog entry or has the no changelog label. It searches for a markdown file matching the PR number in the .changes/ directory structure:
Sources: .github/workflows/ci.yml33-57
The rustfmt job uses nightly Rust to enforce code formatting:
nightly-2025-09-28 with rustfmt componentcargo +nightly-2025-09-28 fmt --all -- --checkSources: .github/workflows/ci.yml59-70
The lint-toml-files job verifies Cargo.toml files are alphabetically sorted:
cargo-sort toolcargo sort -w --checkSources: .github/workflows/ci.yml72-82
The prevent-openssl job ensures OpenSSL hasn't been added to the dependency tree:
.github/workflows/scripts/verify_openssl.shSources: .github/workflows/ci.yml84-90
Cargo Verification Matrix Structure
The matrix defines 17 distinct verification jobs that run in parallel with fail-fast: false, allowing all jobs to complete even if some fail. Each job has a 45-minute timeout and uses BuildJet caching for Cargo registry and build artifacts. The matrix tests multiple feature flag combinations, WASM target compatibility, and native vs WASM executor modes.
Key verification patterns:
| Pattern | Purpose | Example |
|---|---|---|
| WASM Target Checks | Verify crates compile to WASM | check -p fuel-core-client --target wasm32-unknown-unknown |
| Feature Combinations | Test different feature flags | nextest run --all-features --workspace |
| No Default Features | Verify minimal builds work | nextest run -p fuel-core --no-default-features |
| WASM Executor Mode | Force WASM execution path | FUEL_ALWAYS_USE_WASM=true nextest run |
| Version Compatibility | Test against locked versions | check --manifest-path version-compatibility/Cargo.toml |
Sources: .github/workflows/ci.yml92-184
The cargo-test-kms job tests AWS KMS integration with real cloud resources:
This job only runs on non-fork repositories (if: github.event.repository.fork == false) to protect AWS credentials. It uses OIDC to assume an IAM role for secure credential management.
Sources: .github/workflows/ci.yml202-236
The leader-lock-integration-tests job tests distributed locking with Redis:
apt-get install -y redis-serverredis-server --daemonize yesredis-cli MONITORcargo test --features leader_lock -- --test-threads=1The tests run single-threaded to avoid lock contention and monitor Redis operations for debugging. The job times out after 45 minutes.
Sources: .github/workflows/ci.yml238-268
Release Pipeline Flow
The release process only activates when github.event_name == 'release' && github.event.action == 'published'. The pipeline performs three parallel tasks after tag verification: crate publishing to crates.io, binary compilation for four platforms, and includes the WASM executor in each artifact.
Sources: .github/workflows/ci.yml280-458
The verify-tag-version job ensures the Git tag matches the version in Cargo.toml:
The script uses dasel to parse TOML and compare versions, preventing mismatched releases.
Sources: .github/workflows/ci.yml280-294
The publish-crates job publishes all workspace crates to crates.io:
FuelLabs/publish-crates@v1 actionpublish-delay: 60000 (60 second delay between crates)CARGO_REGISTRY_TOKEN secretSources: .github/workflows/ci.yml296-318
The publish-fuel-core-binary job builds native binaries for four platforms:
| Platform | OS Runner | Target Triple | Cross Image |
|---|---|---|---|
linux | buildjet-4vcpu-ubuntu-2204 | x86_64-unknown-linux-gnu | x86_64-linux-gnu |
linux-arm | buildjet-4vcpu-ubuntu-2204 | aarch64-unknown-linux-gnu | aarch64-linux-gnu |
darwin | macos-latest | x86_64-apple-darwin | (native) |
darwin-arm | macos-latest | aarch64-apple-darwin | (native) |
Each job:
fuel-core-bin and fuel-core-keygen-bin with --features productionfuel-core-wasm-executor.wasm.tar.gz artifact: fuel-core-$VERSION-$TARGET.tar.gzLinux cross-compilation uses custom Docker images defined in ci/Dockerfile.$TARGET-clang with cached layers pushed to GHCR for performance.
Sources: .github/workflows/ci.yml320-458
Docker Build and Publish Pipeline
The Docker workflow implements multi-architecture builds using native runners (no QEMU emulation) for performance. Images are built separately for AMD64 and ARM64, then combined into a single multi-platform manifest. The system publishes to three registries and creates specialized image variants for profiling and E2E testing.
Sources: .github/workflows/docker-images.yml26-122
The main Dockerfile uses cargo-chef for efficient layer caching:
Stage 1: Planner
Stage 2: Builder
Stage 3: Runtime
The builder stage downloads chain-configuration from GitHub and uses Docker BuildKit cache mounts to share Cargo registry across builds. The runtime image uses Debian Bookworm Slim (same base as Rust images) to prevent dependency mismatches.
Sources: deployment/Dockerfile1-99
The workflow uses buildkit-cache-dance to inject GitHub Actions cache into Docker builds:
This technique avoids cache invalidation issues with Docker layer caching by managing cache outside of Docker layers. The skip-extraction parameter prevents re-extracting when cache hits.
Sources: .github/workflows/docker-images.yml71-94
The docker/metadata-action generates multiple tags per image:
| Tag Type | Pattern | Example | When Applied |
|---|---|---|---|
sha | sha-{short_sha} | sha-a1b2c3d | Always |
ref | {branch} | master | On branch push |
ref | {tag} | v0.32.0 | On release |
semver | {version} | 0.32.0 | On release |
timestamp | sha-{sha}-{timestamp} | sha-a1b2c3d-20250115123456 | Always |
latest | latest | latest | On default branch |
The profiling variant appends -debug suffix, and E2E client appends -e2e-client suffix to all tags.
Sources: .github/workflows/docker-images.yml171-184 .github/workflows/docker-images.yml240-253 .github/workflows/docker-images.yml335-348
Images are pushed to three registries:
GitHub Container Registry (GHCR)
ghcr.io/fuellabs/fuel-coreGITHUB_TOKENAmazon ECR Public
public.ecr.aws/fuellabs/fuel-coreus-east-1 (ECR Public only exists here)Docker Hub
docker.io/fuellabs/fuel-coreDOCKER_IO_READ_ONLY_TOKENThe multi-platform manifest combines AMD64 and ARM64 digests using docker buildx imagetools create.
Sources: .github/workflows/docker-images.yml146-194
Automated Dependency Updates
The dependencies.yml workflow runs weekly to keep Cargo.lock current. It uses gh CLI to manage PRs, editing existing ones or creating new ones as needed. The workflow requires contents: write and pull-requests: write permissions.
Environment variable RUSTC_BOOTSTRAP=1 allows running nightly features on stable Rust for dependency resolution. The PR body includes formatted output from cargo update showing all version changes.
Sources: .github/workflows/dependencies.yml1-116
The ci_checks.sh script replicates most CI checks locally for rapid iteration:
Requirements:
1.90.0 stable toolchaincargo-sort, cargo-make, cargo-nextestThe script excludes jobs that require external resources (KMS, Redis) or platform-specific builds (cross-compilation, Docker).
Sources: ci_checks.sh1-40
The rust-toolchain.toml file pins the Rust version for consistent builds:
This ensures developers and CI use the same Rust version (1.90.0) with WASM target pre-installed. The file is respected by rustup automatically.
Sources: rust-toolchain.toml1-3
The CI/CD pipeline enforces comprehensive quality checks through:
cargo update PRsAll workflows use BuildJet runners for performance, implement aggressive caching strategies, and enforce strict quality gates before merging. The system handles the complete release lifecycle from code verification through binary distribution without manual intervention.
Refresh this wiki