`ferrflow release`

Lance le pipeline complet de release : bump des versions, mise à jour des changelogs, commit, tag, push et création de la release.

ferrflow release [OPTIONS]

Option	Description
`--force`	Autoriser les floating tags à reculer vers une version inférieure
`--force-version`	Forcer une version spécifique, sans analyser les commits. Format : `VERSION` (repo simple) ou `NAME@VERSION` (monorepo)
`--channel`	Canal de pré-release à utiliser (ex. `beta`, `rc`, `dev`)
`--draft`	Créer les releases en brouillon (GitHub uniquement). Un `ferrflow release` ultérieur sans `--draft` détecte et publie automatiquement les brouillons existants
`--force-unlock`	Forcer la levée d'un verrou `.git/ferrflow.lock` existant. À n'utiliser que si aucun autre `ferrflow release` n'est en cours — par exemple après un crash ayant laissé le fichier de verrou

Ce que ça fait :

Scanne les commits depuis le dernier tag pour chaque package
Détermine l'incrément de version à partir des Conventional Commits
Met à jour tous les versionedFiles avec la nouvelle version
Ajoute la nouvelle section au CHANGELOG.md
Crée un commit git, ouvre une PR, ou passe (selon releaseCommitMode)
Crée et pousse le tag git
Crée une release GitHub/GitLab avec le changelog comme notes

`ferrflow check`

Prévisualiser ce que ferrflow release ferait sans effectuer de changements.

ferrflow check [OPTIONS]

Option	Description
`--json`	Sortie au format JSON
`--channel`	Canal de pré-release à utiliser (ex. `beta`, `rc`, `dev`)
`--comment`	Poster un commentaire de prévisualisation sur la PR/MR courante

`ferrflow publish`

Exécuter les publishers configurés pour la version actuellement publiée de chaque package — sans bumper, committer ni tagger. ferrflow release exécute déjà vos publishers à la fin d'une release ; ferrflow publish sert lorsque vous préférez les exécuter dans un job CI séparé disposant de la toolchain de build et de l'authentification registre dont les publishers ont besoin (docker buildx, helm, un dist/ compilé, …) — ce que votre job de release n'a pas forcément.

ferrflow publish [PACKAGE]

Argument	Description
`[PACKAGE]`	Publier un seul package par son nom. Omettre pour exécuter les publishers de chaque package qui en déclare.

Il lit la version actuelle de chaque package depuis ses versionedFiles (ou le dernier tag correspondant pour les packages tag-only), donc à exécuter après que ferrflow release a coupé la version — typiquement depuis un workflow déclenché par le tag de release. Les publishers sont idempotents : tout ce qui est déjà sur le registre est ignoré, donc une ré-exécution est sûre. Utilisez l'option globale --dry-run pour prévisualiser sans publier.

L'Action GitHub l'expose via mode: publish — elle installe le binaire et exécute ferrflow publish pour vous, de sorte qu'un job déclenché par le tag n'a plus qu'à mettre en place la toolchain dont ses publishers ont besoin :

on:
  push:
    tags: ["v*"]
jobs:
  publish:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      packages: write
    steps:
      - uses: actions/checkout@v6
      - uses: docker/setup-buildx-action@v4
      - uses: docker/login-action@v4
        with:
          registry: ghcr.io
          username: ${{ github.actor }}
          password: ${{ secrets.GITHUB_TOKEN }}
      - uses: FerrLabs/FerrFlow@v5
        with:
          mode: publish

`ferrflow changelog`

Générer ou mettre à jour CHANGELOG.md uniquement, sans bumper les versions ni créer de tags.

ferrflow changelog

Ne prend aucune option spécifique. Utilisez l'option globale --dry-run pour afficher l'entrée sans l'écrire.

`ferrflow init`

Générer un fichier de configuration pour le repository courant. Détecte les fichiers de version existants (Cargo.toml, package.json, etc.) et génère la configuration appropriée.

ferrflow init [OPTIONS]

Option	Description
`--format`	Format du fichier de configuration : `json`, `json5` ou `toml`

`ferrflow status`

Afficher la version actuelle de chaque package et si une release serait déclenchée.

ferrflow status [OPTIONS]

Option	Description
`--output`	Format de sortie : `text` (défaut) ou `json`

Exemple de sortie :

api    1.2.3   minor bump pending (1 feat commit)
site   0.4.1   no release (only chore commits)

`ferrflow version`

Afficher la version actuelle d'un ou de tous les packages. Utile dans les scripts CI.

ferrflow version [PACKAGE] [OPTIONS]

Option	Description
`--json`	Sortie au format JSON

Retourne la version depuis le dernier tag git correspondant au modèle de tag du package.

`ferrflow tag`

Afficher le dernier tag pour un ou tous les packages.

ferrflow tag [PACKAGE] [OPTIONS]

Option	Description
`--json`	Sortie au format JSON

`ferrflow validate`

Valider la configuration et les fichiers versionnés qu'elle référence, sans rien bumper. Utilisez --repo pour valider un dépôt distant plutôt que l'arbre de travail.

ferrflow validate [OPTIONS]

Option	Description
`--json`	Sortie au format JSON
`--repo`	Dépôt distant à valider (ex. `owner/repo` pour GitHub, ou `gitlab:group/project`)
`--ref`	Ref git pour la validation distante (branche, tag ou commit)

`ferrflow completions`

Générer un script de complétion shell et l'afficher sur la sortie standard.

ferrflow completions <SHELL>

est l'un de bash, elvish, fish, powershell ou zsh.

Options globales

Ces options fonctionnent avec toutes les commandes :

Option	Description
`--dry-run`	Montrer ce qui se passerait sans effectuer de changements
`--verbose`, `-v`	Sortie détaillée, incluant les hashes de commits et les diffs de fichiers
`--config`	Chemin vers un fichier de configuration personnalisé (défaut : auto-détecté). Accepte aussi la variable d'environnement `FERRFLOW_CONFIG`.
`--version`	Afficher la version de FerrFlow et quitter
`--help`, `-h`	Afficher l'aide