@ferrflow/doc 7.25.1 → 7.25.3
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.
|
@@ -212,6 +212,10 @@ jobs:
|
|
|
212
212
|
|
|
213
213
|
**Works with:** `releaseCommitMode: pr` only. Requires `pull-requests: write` permission.
|
|
214
214
|
|
|
215
|
+
The pull request title lists the packages being released, and forges cap it: 255 characters on GitLab, Gitea and Forgejo, 256 on GitHub. A monorepo releasing many packages at once therefore gets a title that ends in `and N more`. Nothing is lost, the description always carries the full list, one line per tag.
|
|
216
|
+
|
|
217
|
+
If the release pull request cannot be opened or updated, the run fails rather than warning. That covers the forge refusing it, the lookup for an existing one failing, and FerrFlow not being able to reach a forge at all, which is usually a missing or expired token. A PR-mode release that opened no pull request has released nothing, so it must not leave the pipeline green.
|
|
218
|
+
|
|
215
219
|
## Combining strategies
|
|
216
220
|
|
|
217
221
|
A common production setup combines push-to-main for versioning with tag-triggered builds:
|
|
@@ -203,6 +203,10 @@ jobs:
|
|
|
203
203
|
|
|
204
204
|
**Quand l'utiliser :** Quand vous voulez reviewer les bumps de version, ou quand la protection de branche empeche les push directs sur main.
|
|
205
205
|
|
|
206
|
+
Le titre de la pull request liste les packages publies, et les forges le plafonnent : 255 caracteres sur GitLab, Gitea et Forgejo, 256 sur GitHub. Un monorepo qui publie beaucoup de packages d'un coup obtient donc un titre qui se termine par `and N more`. Rien n'est perdu, la description porte toujours la liste complete, une ligne par tag.
|
|
207
|
+
|
|
208
|
+
Si la pull request de release ne peut pas etre ouverte ou mise a jour, l'execution echoue au lieu d'avertir. Cela couvre le refus de la forge, l'echec de la recherche d'une PR existante, et le cas ou FerrFlow ne peut joindre aucune forge, en general un token manquant ou expire. Une release en mode PR qui n'a ouvert aucune pull request n'a rien publie, elle ne doit pas laisser le pipeline au vert.
|
|
209
|
+
|
|
206
210
|
## Securite de concurrence
|
|
207
211
|
|
|
208
212
|
Depuis la v5.2, `ferrflow release` acquiert `ferrflow.lock` de maniere atomique (`O_CREAT|O_EXCL`) au debut de chaque execution mutante. Le lockfile se trouve dans le git dir commun du depot, c'est-a-dire `.git/` dans un checkout ordinaire et le `.git/` du checkout principal quand vous lancez depuis un worktree lie, si bien que tous les worktrees d'un depot partagent un seul verrou. C'est le comportement voulu : ils poussent vers le meme remote et se disputent les memes refs, donc un verrou par worktree n'empecherait rien. Une seconde invocation concurrente sur le meme depot echoue immediatement avec une erreur claire au lieu de courir contre les refs git. Le scenario classique est une release declenchee manuellement qui demarre en meme temps qu'un `auto-release` planifie en cron, ce qui produit des jeux de tags poussés à moitié, des refus non fast-forward ou des draft releases dupliquees.
|