CI/CD para Rust
Um pipeline robusto de Rust executa fmt, clippy, test e build --release em cada PR, armazena em cache target/ e o índice do registro, e publica binários ou contêineres em tags.
Receita
# .github/workflows/ci.yml
name: ci
on: [push, pull_request]
jobs:
rust:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: dtolnay/rust-toolchain@stable
with:
toolchain: 1.97.0
components: rustfmt, clippy
- uses: Swatinem/rust-cache@v2
- run: cargo fmt --all -- --check
- run: cargo clippy --all-targets --all-features -- -D warnings
- run: cargo test --all-features
- run: cargo build --release --lockedQuando usar isso:
- Todo repositório de equipe com mais de um contribuidor
- Antes de habilitar o deploy automático para staging
- Quando o tempo de CI exceder 10 minutos sem cache
Exemplo de Trabalho
strategy:
matrix:
target:
- x86_64-unknown-linux-gnu
- aarch64-unknown-linux-gnu
steps:
- run: rustup target add ${{ matrix.target }}
- run: cross build --release --target ${{ matrix.target }}# Paridade local
cargo fmt --all -- --check
cargo clippy --all-targets -- -D warnings
cargo testO que isso demonstra:
- O pin da toolchain corresponde ao MSRV de produção
rust-cacherestaura dependências entre execuções- A matriz valida artefatos compilados cruzados
Análise Profunda
Camadas de Cache
| Camada | Ferramenta |
|---|---|
Registro + target/ | Swatinem/rust-cache |
| sccache | Cache remoto do compilador para grandes organizações |
| Cache de camada Docker | Etapa Dockerfile apenas de dependências |
Automação de Release
A tag v1.2.3 aciona:
cargo build --release- SBOM /
cargo auditable(opcional) - Envio de contêiner ou anexo de assets de GitHub Release
Use cargo-release ou release-plz para versionamento de crates em bibliotecas.
Armadilhas
- Sem
--lockedno CI - o desvio do lockfile envia dependências quebradas. Correção: falhar o CI se o lock estiver desatualizado. - Avisos do Clippy ignorados - a dívida técnica se acumula. Correção:
-D warningsno branch principal. - Testes que exigem banco de dados Docker - instáveis sem um contêiner de serviço. Correção:
services: postgresno Actions ou modo offline do sqlx. - Explosão da matriz de features - 2^n combinações. Correção: testar
defaultmaisall-featuresem um agendamento noturno. - Grandes testes de integração em cada PR - feedback lento. Correção: dividir o job rápido
cargo test --lib.
Alternativas
| Alternativa | Usar Quando | Não Usar Quando |
|---|---|---|
| GitLab CI | Organização no GitLab | Já usa Actions |
| Buildkite | Agentes customizados | Projeto OSS simples |
cargo nextest | Runner de testes mais rápido | Suítes de testes minúsculas |
FAQs
Toolchain estável vs. fixada?
Fixe 1.97.0 (ou MSRV) no CI; documente o processo de atualização no guia da equipe.
Como fazer cache do sqlx offline?
Commite o diretório .sqlx/; defina SQLX_OFFLINE=true no ambiente de CI.
Deploy a partir de segredos do CI?
Use OIDC para a nuvem (sem chaves AWS de longa duração); injete DATABASE_URL apenas no momento do deploy.
Nightly rustc no CI?
Job opcional de miri ou preview da edição 2024; não bloqueie PRs em falhas exclusivas do nightly.
Relacionados
Versões da Stack: Esta página foi escrita para Rust 1.97.0 (edição 2024), Tokio 1.x, Axum 0.8, serde 1.0, sqlx 0.8, clap 4, e Polars 0.46+.