Architecture et CI CD

Architecture et CI/CD

Modèle de branches

Le dépôt n'a pas de branche de développement partagée. Chaque forme de distribution vit sur sa propre branche, indépendante des autres :

Branche	Contenu	Merge vers main ?
main	Page d'accueil du dépôt uniquement (README.md)	—
web-converter	App web statique	Non (déploie directement depuis elle-même)
cli-converter	CLI Node.js	Non
browser-extension	Extension Chrome/Edge	Non
desktop-app	App de bureau Electron	Non
node-library	Bibliothèque Node.js (package npm anyform)	Non

main a historiquement servi de point de fusion pour web-converter (pour que le déploiement GitHub Pages, initialement branché sur push: main, se déclenche). Ce n'est plus nécessaire : deploy-pages.yml se déclenche directement sur push: web-converter, donc main a été vidé de tout code applicatif et ne sert plus que de page d'accueil (README avec liens vers les 5 branches, le site déployé et les releases).

node-library est partie de cli-converter (même code lib/), sans Commander ni bin/anyform.js — un package npm installable plutôt qu'un outil en ligne de commande. Voir Bibliotheque Node.

Versioning automatique

Chaque branche applicative a son propre workflow bump-version.yml qui incrémente automatiquement un numéro de version à chaque push :

Branche	Fichier versionné	Déclenché par
web-converter	VERSION (texte brut)	tout push
cli-converter	package.json	tout push
browser-extension	manifest.json	tout push
desktop-app	package.json, intégré au workflow de build (voir App de Bureau)	tout push
node-library	package.json, intégré au workflow de publication (voir Bibliotheque Node)	push touchant index.js/lib//package.json

Chaque workflow a un garde-fou if: github.actor != 'github-actions[bot]' pour éviter une boucle infinie (le commit de bump ne redéclenche pas un nouveau bump).

Pipelines CI par branche

Branche	Workflow(s)	Ce qu'ils font
main	—	aucun (page d'accueil statique)
web-converter	deploy-pages.yml, bump-version.yml	déploiement GitHub Pages + versioning
cli-converter	bump-version.yml	versioning uniquement (pas de publication npm)
browser-extension	bump-version.yml	versioning uniquement (pas de publication Web Store)
desktop-app	build-desktop.yml	bump → build (3 OS) → release GitHub (voir App de Bureau)
node-library	publish-npm.yml	bump → npm publish (voir Bibliotheque Node)

Pourquoi le déploiement GitHub Pages doit être autorisé explicitement par branche

L'environnement github-pages (créé automatiquement par GitHub) a une politique de branches de déploiement. Si elle est restreinte à main (comportement par défaut de certains flux d'activation de Pages) et que le workflow essaie de déployer depuis web-converter, le job échoue quasi instantanément (~2s, avant même le premier step) — symptôme facile à confondre avec un bug du workflow. Fix : Settings → Environments → github-pages → Deployment branches and tags → autoriser web-converter.

Pourquoi le job build de desktop-app repart de ref: desktop-app

Par défaut, actions/checkout récupère le commit qui a déclenché le run (github.sha), pas la HEAD actuelle de la branche. Si un job précédent du même run (bump) a poussé un nouveau commit entre-temps, un checkout par défaut manquerait ce commit. D'où le ref: desktop-app explicite sur les jobs build et release, pour toujours repartir de la HEAD la plus récente de la branche.

Un oubli de cette précaution sur le job release (checkout par défaut au lieu de ref: desktop-app) a d'ailleurs causé un bug réel : le tag de la release ne correspondait pas au numéro de version dans les noms de fichiers, le temps de le corriger.