FerrisGitCI/CD
Du push à la pipeline
Décrivez les jobs dans .ferrisgit-ci.yml à la racine du dépôt. Après chaque push réussi, FerrisGit lit le fichier sur la branche par défaut et crée une pipeline. Activez l'interrupteur pour observer le comportement de l'ordonnanceur lorsqu'un job échoue.
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 réussie
lint
formatréussi
clippyréussi
test
testréussi
format et clippy démarrent ensemble ; test déclare needs: [format, clippy] et démarre quand les deux ont réussi.
- Deux façons d'exécuter un job
- Runners Docker : un binaire léger
ferrisgit-runnerinterroge le serveur et exécute chaque job dans un conteneur. Ou Kubernetes : le serveur crée un Pod par job dans votre cluster. - Des erreurs explicites
- Un fichier présent mais invalide crée une pipeline en échec qui porte le message de l'analyseur, affiché dans l'interface.
- Variables et caches
- Variables CI par dépôt, chiffrées au repos en AES-256-GCM (runners Docker). Caches par job avec Kubernetes.
Évaluez FerrisGit, puis déployez votre propre instance.
L'instance publique permet de découvrir le produit. Votre instance conserve votre code.
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