FerrisGitCI/CD
Del push al pipeline
Los trabajos se describen en .ferrisgit-ci.yml, en la raíz del repositorio. Tras cada push correcto, FerrisGit lee el archivo en la rama predeterminada y crea una pipeline. El interruptor permite observar el comportamiento del planificador cuando un trabajo falla.
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 superada
lint
formatcorrecto
clippycorrecto
test
testcorrecto
format y clippy arrancan juntos; test declara needs: [format, clippy] y arranca cuando ambos han terminado bien.
- Dos formas de ejecutar un trabajo
- Runners Docker: un binario ligero
ferrisgit-runnerconsulta al servidor y ejecuta cada trabajo en un contenedor. O Kubernetes: el servidor crea un Pod por trabajo en su clúster. - Errores explícitos
- Un archivo presente pero inválido crea una pipeline fallida que lleva el mensaje del analizador, mostrado en la interfaz.
- Variables y cachés
- Variables de CI por repositorio, cifradas en reposo con AES-256-GCM (runners Docker). Cachés por trabajo con Kubernetes.
Evaluar FerrisGit y desplegar una instancia propia.
La instancia pública permite conocer el producto. Una instancia propia conserva el código.
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