FerrisGitCI/CD
Dal push alla pipeline
I job si descrivono in .ferrisgit-ci.yml, alla radice del repository. Dopo ogni push riuscito, FerrisGit legge il file sul branch predefinito e crea una pipeline. L'interruttore permette di osservare il comportamento dello scheduler quando un job fallisce.
stages: [lint, test]
jobs:
format:
stage: lint
image: rust:1
script:
- rustup component add rustfmt
- cargo fmt --all -- --check
clippy:
stage: lint
image: rust:1
script:
- rustup component add clippy
- cargo clippy --all-targets -- -D warnings
test:
stage: test
image: rust:1
needs: [format, clippy]
script:
- cargo test --all-targets
Pipeline riuscita
lint
formatriuscito
clippyriuscito
test
testriuscito
format e clippy partono insieme; test dichiara needs: [format, clippy] e parte quando entrambi sono riusciti.
- Due modi di eseguire un job
- Runner Docker: un binario leggero
ferrisgit-runnerinterroga il server ed esegue ogni job in un container. Oppure Kubernetes: il server crea un Pod per job nel proprio cluster. - Errori espliciti
- Un file presente ma non valido crea una pipeline fallita che porta il messaggio del parser, mostrato nell'interfaccia.
- Variabili e cache
- Variabili CI per repository, cifrate a riposo con AES-256-GCM (runner Docker). Cache per job con Kubernetes.
Valutare FerrisGit, poi distribuire la propria istanza.
L'istanza pubblica consente di conoscere il prodotto. La propria istanza custodisce il codice.
git clone https://github.com/Masmarino/FerrisGit.git
cd FerrisGit
cp .env.example .env
# set POSTGRES_PASSWORD, JWT_SECRET, SETTINGS_ENCRYPTION_KEY and the admin password in .env
docker compose up -d --build