Installation locale

Cargo

cargo install ferrflow

npm

npm install -g @ferrlabs/ferrflow
# ou en dépendance de développement
npm install -D @ferrlabs/ferrflow

WASM (navigateur)

npm install @ferrlabs/ferrflow-wasm

Utilisez FerrFlow directement dans le navigateur — parsez les commits, calculez les incréments de version et générez des changelogs côté client sans backend.

Binaire

Téléchargez un binaire pré-compilé depuis les Releases :

# Linux x86_64
curl -L https://github.com/FerrLabs/FerrFlow/releases/latest/download/ferrflow-linux-x64.tar.gz | tar xz
sudo mv ferrflow /usr/local/bin/

Docker

docker run --rm -v $(pwd):/repo ghcr.io/ferrlabs/ferrflow:latest check

Installation CI

La méthode recommandée pour utiliser FerrFlow en CI est la GitHub Action — aucune étape d'installation nécessaire :

- uses: FerrLabs/ferrflow@v5
  env:
    GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}

Consultez GitHub Actions et GitLab CI pour des exemples complets.

Vérification

ferrflow --version

Migration depuis la v4

Si vous suivez la configuration documentée pour GitHub Actions / GitLab CI (GITHUB_TOKEN / CI_JOB_TOKEN en variable d'environnement), aucun changement n'est nécessaire — il suffit de bumper le pin de l'action à FerrLabs/ferrflow@v5 et le binaire à la v5.x.

Le seul changement cassant de la v5.0 est interne : FerrFlow n'injecte plus les tokens dans l'URL distante lors des push. Il utilise désormais le protocole standard de credential helper de git (GIT_ASKPASS). C'est invisible pour quiconque suit la configuration recommandée, mais si vous aviez un workflow custom qui s'appuyait sur des tokens injectés dans l'URL — par exemple, un runner self-hosted avec un remote pré-amorcé https://x-access-token:$TOKEN@github.com/... — passez à GITHUB_TOKEN (ou FERRFLOW_TOKEN) en variable d'environnement et FerrFlow se charge du reste.

Depuis la v5.2, les releases sont signées via Sigstore et embarquent un SBOM CycloneDX — voir Vérifier les releases.