@ferrflow/doc 7.24.3 → 7.24.5
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
|
@@ -189,7 +189,7 @@ Global settings that apply to all packages.
|
|
|
189
189
|
| `releaseCommitMode` | string | `"commit"` | How to handle the release commit: `"commit"`, `"pr"`, or `"none"` |
|
|
190
190
|
| `releaseCommitScope` | string | `"grouped"` | In a monorepo where several packages are bumped at once, whether to create a single `"grouped"` commit or one commit `"per-package"`. Only matters when multiple packages bump. |
|
|
191
191
|
| `releaseCommitBody` | string | `"none"` | What goes in the body of the release commit, below the subject. `"none"` keeps the single-line subject. `"summary"` lists one line per released package with its commit count. `"full"` embeds the changelog section written for each package — under `"grouped"` scope each section is headed `## <package> <version>`. |
|
|
192
|
-
| `forge` | string | `"auto"` | Git forge override: `"auto"` detects from the remote URL, and for an unrecognised host it probes the API over HTTPS to auto-detect a self-hosted **GitLab**, **GitHub Enterprise**, or **Gitea / Forgejo** instance (cached, ~2s, best-effort). The same answer picks the credential git pushes with, so a self-hosted GitLab pushes with `GITLAB_TOKEN` whatever its host name. Each forge pushes with its own variable, and `GITHUB_TOKEN` only goes to a remote recognised as GitHub: an unrecognised host gets `FERRFLOW_TOKEN` or nothing, with a warning saying why. Until the next major, Gitea / Forgejo still falls back to `GITHUB_TOKEN` (the name Gitea and Forgejo Actions give their job token) when neither `GITEA_TOKEN` nor `FORGEJO_TOKEN` is set, and warns. Set `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg), or `"bitbucket"` (Bitbucket Cloud) to force a forge — needed only when the host isn't reachable over HTTPS or you want to skip probing. Gitea auth uses `GITEA_TOKEN` / `FORGEJO_TOKEN`; Bitbucket uses `BITBUCKET_TOKEN`. All cover release creation — on Bitbucket, which has no release object, the release is the annotated tag FerrFlow pushes. PR mode is GitHub/GitLab only. |
|
|
192
|
+
| `forge` | string | `"auto"` | Git forge override: `"auto"` detects from the remote URL, and for an unrecognised host it probes the API over HTTPS to auto-detect a self-hosted **GitLab**, **GitHub Enterprise**, or **Gitea / Forgejo** instance (cached, ~2s, best-effort). GitHub Enterprise is only recognised by the `X-GitHub-Enterprise-Version` header its API sends, so a host that merely answers `/api/v3` is not taken for GitHub, and an instance in private mode is still detected. The same answer picks the credential git pushes with, so a self-hosted GitLab pushes with `GITLAB_TOKEN` whatever its host name. Each forge pushes with its own variable, and `GITHUB_TOKEN` only goes to a remote recognised as GitHub: an unrecognised host gets `FERRFLOW_TOKEN` or nothing, with a warning saying why. Until the next major, Gitea / Forgejo still falls back to `GITHUB_TOKEN` (the name Gitea and Forgejo Actions give their job token) when neither `GITEA_TOKEN` nor `FORGEJO_TOKEN` is set, and warns. Set `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg), or `"bitbucket"` (Bitbucket Cloud) to force a forge — needed only when the host isn't reachable over HTTPS or you want to skip probing. Gitea auth uses `GITEA_TOKEN` / `FORGEJO_TOKEN`; Bitbucket uses `BITBUCKET_TOKEN`. All cover release creation — on Bitbucket, which has no release object, the release is the annotated tag FerrFlow pushes. PR mode is GitHub/GitLab only. |
|
|
193
193
|
| `skipCi` | boolean | depends on mode | Add `[skip ci]` to release commits. Defaults to `true` when mode is `"commit"`, `false` otherwise. |
|
|
194
194
|
| `commitSkipMarkers` | array | `["[skip ci]", "[ci skip]", "[no ci]", "[skip actions]", "[actions skip]"]` | Markers that cause FerrFlow to skip a commit when computing the next version. Matched case-insensitively, subject line only. |
|
|
195
195
|
| `commitFormats` | object | permissive conventional | Which commit subjects map to which bump level. Each of `major` / `minor` / `patch` takes a pattern string, a list of patterns, or `"all"` as a catch-all; `*` matches any run of characters (including `/`) and `?` exactly one. Resolution is major → minor → patch, first match wins. `caseSensitive` (default `true`) lowercases both sides when false. Defaults also accept capitalised and slash-separated variants (`Feat:`, `feat/`, `feature:`, `Fix/`, `Perf:`, `Refactor/`, and so on), listed in full under [permissive defaults](/docs/reference/conventional-commits). Breaking markers (`feat!:`, `fix(api)!:`, a `BREAKING CHANGE:` footer) are always detected regardless of what is configured. |
|
package/docs-en/reference/cli.md
CHANGED
|
@@ -393,9 +393,9 @@ ferrflow doctor [OPTIONS]
|
|
|
393
393
|
| Flag | Description |
|
|
394
394
|
| ---------------- | --------------------------------------------------------------------- |
|
|
395
395
|
| `--format <FMT>` | `human` (default) or `json` |
|
|
396
|
-
| `--online` | Also probe the forge API (GitHub rate limit / auth); requires a token |
|
|
396
|
+
| `--online` | Also probe the forge API (GitHub rate limit / auth, self-hosted forge detection); requires a token |
|
|
397
397
|
|
|
398
|
-
The report groups checks into five sections — **Repo** (git repository, commit history, clean working tree, git identity, remote, tags), **Config** (which config file wins, whether it parses, plus the full `ferrflow validate` check suite), **Versioning** (strategy, each package's on-disk version, and whether its lockfile agrees with it), **Forge** (detected forge and whether
|
|
398
|
+
The report groups checks into five sections — **Repo** (git repository, commit history, clean working tree, git identity, remote, tags), **Config** (which config file wins, whether it parses, plus the full `ferrflow validate` check suite), **Versioning** (strategy, each package's on-disk version, and whether its lockfile agrees with it), **Forge** (detected forge, and whether the token that forge actually uses is in the environment; with `--online` the forge is also probed for a self-hosted host), and **CI** (workflow files, and whether a workflow pins the `FerrLabs/FerrFlow` action). Every check reports green, a warning, or an error.
|
|
399
399
|
|
|
400
400
|
Two of the **Versioning** checks are about lockfiles, and both matter for anything that builds with `--locked`. A lockfile recording a different version than the manifest beside it is reported outright, since that combination makes `cargo build --locked` refuse to run. A lockfile that is not covered by [`updateLockfiles`](/docs/configuration/config-file/) is flagged before it drifts, because nothing will keep it in step on the next release. Version comparison applies to `Cargo.lock`: pnpm, yarn, poetry, uv, bundler and mix lock dependencies without restating the version of the package that owns them, so there is nothing to compare, and those get the `updateLockfiles` check only.
|
|
401
401
|
|
|
@@ -189,7 +189,7 @@ Paramètres globaux qui s'appliquent à tous les packages.
|
|
|
189
189
|
| `releaseCommitMode` | string | `"commit"` | Gestion du commit de release : `"commit"`, `"pr"` ou `"none"` |
|
|
190
190
|
| `releaseCommitScope` | string | `"grouped"` | Dans un monorepo où plusieurs packages sont bumpés en même temps, créer un seul commit `"grouped"` ou un commit `"per-package"`. N'a d'effet que quand plusieurs packages bumpent. |
|
|
191
191
|
| `releaseCommitBody` | string | `"none"` | Ce que contient le corps du commit de release, sous la ligne de sujet. `"none"` conserve le sujet sur une seule ligne. `"summary"` liste une ligne par package publié avec son nombre de commits. `"full"` intègre la section de changelog écrite pour chaque package — en scope `"grouped"`, chaque section est titrée `## <package> <version>`. |
|
|
192
|
-
| `forge` | string | `"auto"` | Forçage du forge git : `"auto"` détecte depuis l'URL du remote, et pour un hôte non reconnu il sonde l'API en HTTPS pour auto-détecter une instance auto-hébergée de **GitLab**, **GitHub Enterprise** ou **Gitea / Forgejo** (mis en cache, ~2s, best-effort). Ce même résultat choisit l'identifiant avec lequel git pousse : une instance GitLab auto-hébergée pousse avec `GITLAB_TOKEN`, quel que soit son nom d'hôte. Chaque forge pousse avec sa propre variable, et `GITHUB_TOKEN` ne part que vers un remote reconnu comme GitHub : un hôte non reconnu reçoit `FERRFLOW_TOKEN` ou rien, avec un avertissement qui explique pourquoi. Jusqu'à la prochaine version majeure, Gitea / Forgejo se rabat encore sur `GITHUB_TOKEN` (le nom que Gitea et Forgejo Actions donnent à leur token de job) quand ni `GITEA_TOKEN` ni `FORGEJO_TOKEN` n'est défini, et le signale. Renseignez `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg) ou `"bitbucket"` (Bitbucket Cloud) pour forcer un forge — nécessaire uniquement si l'hôte n'est pas joignable en HTTPS ou pour éviter le sondage. L'auth Gitea utilise `GITEA_TOKEN` / `FORGEJO_TOKEN` ; Bitbucket utilise `BITBUCKET_TOKEN`. Tous couvrent la création de release — sur Bitbucket, qui n'a pas d'objet release, la release est le tag annoté que FerrFlow pousse. Le mode PR reste GitHub/GitLab. |
|
|
192
|
+
| `forge` | string | `"auto"` | Forçage du forge git : `"auto"` détecte depuis l'URL du remote, et pour un hôte non reconnu il sonde l'API en HTTPS pour auto-détecter une instance auto-hébergée de **GitLab**, **GitHub Enterprise** ou **Gitea / Forgejo** (mis en cache, ~2s, best-effort). GitHub Enterprise n'est reconnu que par l'en-tête `X-GitHub-Enterprise-Version` que son API renvoie : un hôte qui se contente de répondre sur `/api/v3` n'est pas pris pour GitHub, et une instance en mode privé est quand même détectée. Ce même résultat choisit l'identifiant avec lequel git pousse : une instance GitLab auto-hébergée pousse avec `GITLAB_TOKEN`, quel que soit son nom d'hôte. Chaque forge pousse avec sa propre variable, et `GITHUB_TOKEN` ne part que vers un remote reconnu comme GitHub : un hôte non reconnu reçoit `FERRFLOW_TOKEN` ou rien, avec un avertissement qui explique pourquoi. Jusqu'à la prochaine version majeure, Gitea / Forgejo se rabat encore sur `GITHUB_TOKEN` (le nom que Gitea et Forgejo Actions donnent à leur token de job) quand ni `GITEA_TOKEN` ni `FORGEJO_TOKEN` n'est défini, et le signale. Renseignez `"github"`, `"gitlab"`, `"gitea"` (Gitea / Forgejo / Codeberg) ou `"bitbucket"` (Bitbucket Cloud) pour forcer un forge — nécessaire uniquement si l'hôte n'est pas joignable en HTTPS ou pour éviter le sondage. L'auth Gitea utilise `GITEA_TOKEN` / `FORGEJO_TOKEN` ; Bitbucket utilise `BITBUCKET_TOKEN`. Tous couvrent la création de release — sur Bitbucket, qui n'a pas d'objet release, la release est le tag annoté que FerrFlow pousse. Le mode PR reste GitHub/GitLab. |
|
|
193
193
|
| `skipCi` | boolean | dépend du mode | Ajouter `[skip ci]` aux commits de release. Par défaut `true` en mode `"commit"`, `false` sinon. |
|
|
194
194
|
| `commitSkipMarkers` | array | `["[skip ci]", "[ci skip]", "[no ci]", "[skip actions]", "[actions skip]"]` | Marqueurs qui font ignorer un commit par FerrFlow lors du calcul de la prochaine version. Comparaison insensible à la casse, sur la ligne de sujet uniquement. |
|
|
195
195
|
| `commitFormats` | object | conventionnel permissif | Quels sujets de commit correspondent à quel niveau de bump. Chacun de `major` / `minor` / `patch` accepte un motif, une liste de motifs, ou `"all"` comme fourre-tout ; `*` correspond à n'importe quelle suite de caractères (y compris `/`) et `?` à exactement un. Résolution : major → minor → patch, premier motif gagnant. `caseSensitive` (défaut `true`) met les deux côtés en minuscules quand il vaut `false`. Les défauts acceptent aussi les variantes capitalisées et séparées par une barre oblique (`Feat:`, `feat/`, `feature:`, `Fix/`, `Perf:`, `Refactor/`, etc.), listées en entier dans [défauts permissifs](/fr/docs/reference/conventional-commits). Les marqueurs de rupture (`feat!:`, `fix(api)!:`, un pied de page `BREAKING CHANGE:`) sont toujours détectés quelle que soit la configuration. |
|
package/docs-fr/reference/cli.md
CHANGED
|
@@ -317,9 +317,9 @@ ferrflow doctor [OPTIONS]
|
|
|
317
317
|
| Option | Description |
|
|
318
318
|
| ---------------- | ------------------------------------------------------------------------------ |
|
|
319
319
|
| `--format <FMT>` | `human` (défaut) ou `json` |
|
|
320
|
-
| `--online` | Sonder aussi l'API de la forge (rate limit / auth GitHub) ; nécessite un token |
|
|
320
|
+
| `--online` | Sonder aussi l'API de la forge (rate limit / auth GitHub, détection d'une forge auto-hébergée) ; nécessite un token |
|
|
321
321
|
|
|
322
|
-
Le rapport groupe les vérifications en cinq sections : **Repo** (dépôt git, historique de commits, arbre de travail propre, identité git, remote, tags), **Config** (quel fichier de config l'emporte, s'il parse, plus toute la suite de vérifications de `ferrflow validate`), **Versioning** (stratégie, version sur disque de chaque package, et si son lockfile est d'accord avec elle), **Forge** (forge détectée et présence
|
|
322
|
+
Le rapport groupe les vérifications en cinq sections : **Repo** (dépôt git, historique de commits, arbre de travail propre, identité git, remote, tags), **Config** (quel fichier de config l'emporte, s'il parse, plus toute la suite de vérifications de `ferrflow validate`), **Versioning** (stratégie, version sur disque de chaque package, et si son lockfile est d'accord avec elle), **Forge** (forge détectée, et présence dans l'environnement du token que cette forge utilise réellement ; avec `--online`, la forge d'un hôte auto-hébergé est aussi sondée) et **CI** (fichiers de workflow, et si un workflow épingle l'action `FerrLabs/FerrFlow`). Chaque vérification est verte, un avertissement, ou une erreur.
|
|
323
323
|
|
|
324
324
|
Deux des vérifications **Versioning** portent sur les lockfiles, et les deux comptent pour tout ce qui compile avec `--locked`. Un lockfile qui enregistre une version différente du manifeste voisin est signalé directement, cette combinaison faisant échouer `cargo build --locked`. Un lockfile que [`updateLockfiles`](/fr/docs/configuration/config-file/) ne couvre pas est signalé avant qu'il ne dérive, puisque rien ne le maintiendra à jour à la prochaine release. La comparaison de version s'applique à `Cargo.lock` : pnpm, yarn, poetry, uv, bundler et mix verrouillent les dépendances sans redonner la version du package qui les possède, il n'y a donc rien à comparer, et ceux-là n'ont que la vérification `updateLockfiles`.
|
|
325
325
|
|