FerrisGitCI/CD
Vom Push zur Pipeline
Die Jobs werden in .ferrisgit-ci.yml im Wurzelverzeichnis des Repositorys beschrieben. Nach jedem erfolgreichen Push liest FerrisGit die Datei auf dem Standard-Branch und erstellt eine Pipeline. Mit dem Schalter lässt sich beobachten, wie sich der Scheduler verhält, wenn ein Job fehlschlägt.
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 bestanden
lint
formaterfolgreich
clippyerfolgreich
test
testerfolgreich
format und clippy starten gemeinsam; test deklariert needs: [format, clippy] und startet, sobald beide erfolgreich waren.
- Zwei Wege, einen Job auszuführen
- Docker-Runner: eine schlanke Binary
ferrisgit-runnerfragt den Server ab und führt jeden Job in einem Container aus. Oder Kubernetes: der Server erzeugt pro Job einen Pod in Ihrem Cluster. - Eindeutige Fehlermeldungen
- Eine vorhandene, aber ungültige Datei erzeugt eine fehlgeschlagene Pipeline mit der Meldung des Parsers, sichtbar in der Oberfläche.
- Variablen und Caches
- CI-Variablen pro Repository, mit AES-256-GCM verschlüsselt gespeichert (Docker-Runner). Caches pro Job mit Kubernetes.
FerrisGit evaluieren und die eigene Instanz betreiben.
Die öffentliche Instanz zeigt das Produkt. Die eigene Instanz behält den 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