@ferrflow/doc 7.21.7 → 7.21.9

package/docs-en/ci/gitlab-ci.md

@@ -85,6 +85,8 @@ If no releasable changes are detected, the comment says so.
 <aside class="ferr-aside ferr-aside--note"><div class="ferr-aside__body"><p><code>CI_JOB_TOKEN</code> has permission to post MR notes by default. If your project restricts this, use a project access token with <code>api</code> scope stored as a CI variable.</p>
 </div></aside>
 
+If you store that token as a **protected** variable, GitLab only exposes it to pipelines on protected branches and tags, and a merge request pipeline from an ordinary branch runs without it. FerrFlow then prints `Warning: preview comment not posted: no Gitlab token found in FERRFLOW_TOKEN or GITLAB_TOKEN` and the job still succeeds. Either unprotect the variable or use `CI_JOB_TOKEN`, which every job receives.
+
 ## GitLab Releases
 
 When `GITLAB_TOKEN` is set, FerrFlow creates a GitLab Release with the generated changelog as release notes, matching the behaviour of the GitHub integration.

package/docs-en/reference/cli.md

@@ -76,6 +76,8 @@ ferrflow check [OPTIONS]
 | `--channel <NAME>` | Pre-release channel override (e.g. `beta`, `rc`, `dev`) |
 | `--comment`        | Post a preview comment on the current PR/MR             |
 
+`--comment` needs a forge token (`FERRFLOW_TOKEN`, or the forge's own variable such as `GITHUB_TOKEN` or `GITLAB_TOKEN`). Without one it prints a warning naming the variables it read and posts nothing, but still exits 0, so a pull request from a fork, which gets no secrets, does not fail its pipeline. Outside a pull request or merge request it does nothing.
+
 ---
 
 ## `ferrflow publish`
@@ -190,7 +192,7 @@ ferrflow migrate                        # auto-detect
 ferrflow migrate --from release-please
 ```
 
-JSON, YAML, and JavaScript source configs all work. A JavaScript config (`.releaserc.js`, `.releaserc.cjs`, `.releaserc.mjs`, `release.config.js`, `release.config.cjs`, `release.config.mjs`, `.versionrc.js`) is run with `node` to read what it exports, so it needs Node.js on PATH. Being run is the point worth noticing: that file is a program, and migrating it executes it, along with anything it imports. semantic-release does the same, and there is no way to read an arbitrary module's exports without running it, so migrate only a repository you trust. `--dry-run` is no protection here: `migrate` ignores the flag, so the config runs and `ferrflow.json` is written either way. A YAML config (`.releaserc.yaml`, `.versionrc.yaml`) is parsed directly. After migrating, review the generated config, then run `ferrflow validate` and `ferrflow check`.
+JSON, YAML, and JavaScript source configs all work. A JavaScript config (`.releaserc.js`, `.releaserc.cjs`, `.releaserc.mjs`, `release.config.js`, `release.config.cjs`, `release.config.mjs`, `.versionrc.js`) is run with `node` to read what it exports, so it needs Node.js on PATH. Being run is the point worth noticing: that file is a program, and migrating it executes it, along with anything it imports. semantic-release does the same, and there is no way to read an arbitrary module's exports without running it, so migrate only a repository you trust. `--dry-run` prints the generated config instead of writing `ferrflow.json`, but it is no protection here: reading a JavaScript config still means running it. A YAML config (`.releaserc.yaml`, `.versionrc.yaml`) is parsed directly. After migrating, review the generated config, then run `ferrflow validate` and `ferrflow check`.
 
 ---
 

package/docs-fr/ci/gitlab-ci.md

@@ -72,6 +72,8 @@ ferrflow-preview:
 
 Si aucun changement publiable n'est d\u00e9tect\u00e9, le commentaire l'indique.
 
+Si vous stockez ce token dans une variable **protégée**, GitLab ne l'expose qu'aux pipelines des branches et tags protégés, et le pipeline d'une merge request venant d'une branche ordinaire tourne sans lui. FerrFlow affiche alors `Warning: preview comment not posted: no Gitlab token found in FERRFLOW_TOKEN or GITLAB_TOKEN` et le job réussit quand même. Retirez la protection de la variable, ou utilisez `CI_JOB_TOKEN`, que chaque job reçoit.
+
 ## GitLab Releases
 
 Lorsque `GITLAB_TOKEN` est d\u00e9fini, FerrFlow cr\u00e9e une GitLab Release avec le changelog g\u00e9n\u00e9r\u00e9 comme notes de release, de la m\u00eame mani\u00e8re que l'int\u00e9gration GitHub.

package/docs-fr/reference/cli.md

@@ -45,6 +45,8 @@ ferrflow check [OPTIONS]
 | `--channel <NAME>` | Canal de pré-release à utiliser (ex. `beta`, `rc`, `dev`)       |
 | `--comment`        | Poster un commentaire de prévisualisation sur la PR/MR courante |
 
+`--comment` a besoin d'un token de forge (`FERRFLOW_TOKEN`, ou la variable propre à la forge comme `GITHUB_TOKEN` ou `GITLAB_TOKEN`). Sans token, la commande affiche un avertissement qui nomme les variables lues et ne poste rien, mais sort quand même avec le code 0, pour qu'une pull request venant d'un fork, qui ne reçoit aucun secret, ne fasse pas échouer son pipeline. Hors d'une pull request ou d'une merge request, elle ne fait rien.
+
 ---
 
 ## `ferrflow publish`
@@ -159,7 +161,7 @@ ferrflow migrate                        # auto-détection
 ferrflow migrate --from release-please
 ```
 
-Les configurations source JSON, YAML et JavaScript fonctionnent toutes. Une configuration JavaScript (`.releaserc.js`, `.releaserc.cjs`, `.releaserc.mjs`, `release.config.js`, `release.config.cjs`, `release.config.mjs`, `.versionrc.js`) est exécutée avec `node` pour lire ce qu'elle exporte, Node.js doit donc être dans le PATH. Le mot exécutée compte : ce fichier est un programme, et le migrer le lance, ainsi que tout ce qu'il importe. semantic-release fait la même chose, et il n'existe aucun moyen de lire les exports d'un module arbitraire sans le lancer : ne migrez donc qu'un dépôt de confiance. `--dry-run` ne protège pas : `migrate` ignore ce drapeau, la configuration est donc lancée et `ferrflow.json` écrit dans les deux cas. Une configuration YAML (`.releaserc.yaml`, `.versionrc.yaml`) est parsée directement. Après migration, relisez la configuration générée, puis lancez `ferrflow validate` et `ferrflow check`.
+Les configurations source JSON, YAML et JavaScript fonctionnent toutes. Une configuration JavaScript (`.releaserc.js`, `.releaserc.cjs`, `.releaserc.mjs`, `release.config.js`, `release.config.cjs`, `release.config.mjs`, `.versionrc.js`) est exécutée avec `node` pour lire ce qu'elle exporte, Node.js doit donc être dans le PATH. Le mot exécutée compte : ce fichier est un programme, et le migrer le lance, ainsi que tout ce qu'il importe. semantic-release fait la même chose, et il n'existe aucun moyen de lire les exports d'un module arbitraire sans le lancer : ne migrez donc qu'un dépôt de confiance. `--dry-run` affiche la configuration générée au lieu d'écrire `ferrflow.json`, mais ne protège pas pour autant : lire une configuration JavaScript implique toujours de la lancer. Une configuration YAML (`.releaserc.yaml`, `.versionrc.yaml`) est parsée directement. Après migration, relisez la configuration générée, puis lancez `ferrflow validate` et `ferrflow check`.
 
 ---
 

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@ferrflow/doc",
-  "version": "7.21.7",
+  "version": "7.21.9",
   "description": "Documentation for FerrFlow, the universal semantic versioning CLI. Rendered at ferrflow.com/docs.",
   "license": "MIT",
   "repository": {