This document describes our continuous integration setup and how to reproduce CI checks locally.
Our CI pipeline consists of several jobs that run in parallel and series:
- Purpose: Ensures code formatting and catches common issues
- Runs on:
ubuntu-latest - Checks:
cargo fmt --all -- --check- Rust code formattingcargo clippy --all-targets --all-features -- -D warnings- Linting
- Purpose: Soroban-specific contract validation
- Runs on:
ubuntu-latest - Checks:
- Contract builds for
wasm32-unknown-unknowntarget - Soroban contract optimization
- Contract metadata validation
- WASM inspection
- Contract builds for
- Purpose: Full build and test execution
- Runs on:
macos-latest - Dependencies: Requires
checkandsoroban-checksto pass - Checks:
- Full project build
- Unit test execution
- Integration test placeholder
- Purpose: Security vulnerability scanning
- Runs on:
ubuntu-latest - Checks:
cargo auditfor known vulnerabilities
- Purpose: Code coverage reporting
- Runs on:
ubuntu-latest - Condition: Only on main branch pushes
- Output: Coverage report to Codecov
We use GitHub Actions caching for:
- Cargo registry (
~/.cargo/registry) - Cargo git dependencies (
~/.cargo/git) - Build artifacts (
target/)
Cache keys are based on:
- Runner OS
Cargo.lockfile hash- Job-specific prefixes
- Rust toolchain with components:
rustfmt(formatting)clippy(linting)
- Targets:
wasm32-unknown-unknown(for Soroban contracts)
- Stellar CLI (for contract operations)
- cargo-audit (security auditing)
- cargo-llvm-cov (code coverage)
-
Make the script executable:
chmod +x local-ci.sh
-
Run local CI checks:
./local-ci.sh
If you prefer to run checks manually:
# Install Rust components
rustup component add rustfmt clippy
rustup target add wasm32-unknown-unknown
# Install Stellar CLI (macOS)
brew install stellar-cli
# Install additional tools
cargo install cargo-auditcd stellar-lend
# Check formatting
cargo fmt --all -- --check
# Run clippy
cargo clippy --all-targets --all-features -- -D warningscd stellar-lend
# Build contracts
stellar contract build --verbose
# Optimize contracts
stellar contract optimize --wasm target/wasm32-unknown-unknown/release/*.wasm
# Inspect contracts
stellar contract inspect --wasm target/wasm32-unknown-unknown/release/*-optimized.wasm --output jsoncd stellar-lend
# Build project
cargo build --verbose
# Run tests
cargo test --verbose
# Build documentation
cargo doc --no-depscd stellar-lend
cargo audit# Auto-fix formatting
cargo fmt
# Check what would be changed
cargo fmt -- --check# Auto-fix some clippy issues
cargo clippy --fix
# See all warnings
cargo clippy --all-targets --all-features- Check error messages carefully
- Ensure all dependencies are properly specified
- Verify Soroban SDK version compatibility
# Update dependencies
cargo update
# Check for specific vulnerabilities
cargo audit --db /path/to/advisory-dbThe CI uses these environment variables:
CARGO_TERM_COLOR=always- Colored outputRUST_BACKTRACE=1- Full backtraces on panic
Currently no secrets are required. If you need to add secrets for Soroban network operations:
- Go to your repository settings
- Navigate to "Secrets and variables" → "Actions"
- Add repository secrets as needed
- Reference them in workflow with
${{ secrets.SECRET_NAME }}
-
Format Check Failed:
- Run
cargo fmtlocally - Commit the formatted code
- Run
-
Clippy Failed:
- Fix warnings shown in CI logs
- Consider allowing specific warnings if necessary
-
Build Failed:
- Check Rust version compatibility
- Verify Soroban SDK version
- Check dependency conflicts
-
Test Failed:
- Run tests locally to reproduce
- Check test environment differences
- OS differences: CI uses Ubuntu/macOS, your local might differ
- Rust version: CI uses latest stable, ensure compatibility
- Dependencies: CI installs fresh, local might have cached versions
- Environment: CI has clean environment, local might have extra tools
- Cache hit rates are displayed in CI logs
- If cache misses are frequent, check cache key strategy
- Consider cache size limits (GitHub has 10GB limit)
- Parallel job execution reduces total time
- Consider splitting large test suites
- Use
--releasebuilds only when necessary
When adding new CI checks:
- Test locally first using
local-ci.sh - Update documentation if adding new requirements
- Consider job dependencies to avoid unnecessary runs
- Test with both success and failure scenarios
- Update the local reproduction script
- Check CI status on pull requests
- Monitor build times for performance regression
- Review security audit reports regularly
- Keep dependencies updated
For questions about CI/CD setup, please open an issue or contact the maintainers.