FerrisGitCI/CD
From push to pipeline
Describe the jobs in .ferrisgit-ci.yml at the root of the repository. After every successful push, FerrisGit reads the file on the default branch and creates a pipeline. Use the switch to see how the scheduler behaves when a job fails.
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 passed
lint
formatsucceeded
clippysucceeded
test
testsucceeded
format and clippy start together; test declares needs: [format, clippy] and starts once both have succeeded.
- Two ways to run a job
- Docker runners: a lightweight
ferrisgit-runnerbinary polls the server and runs each job in a container. Or Kubernetes: the server creates one Pod per job in your cluster. - Explicit errors
- A file that is present but invalid creates a failed pipeline that carries the parser's message, shown in the interface.
- Variables and caches
- Per-repository CI variables, encrypted at rest with AES-256-GCM (Docker runners). Per-job caches with Kubernetes.
Evaluate FerrisGit, then deploy your own instance.
The public instance lets you explore the product. Your own instance keeps your 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