@ferrflow/doc 7.24.4 → 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. |
|
|
@@ -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. |
|