RFC : migrer de GitHub vers Forgejo

[shikanime]

Contexte

La fiabilité de GitHub s'est dégradée à répétition en 2025 : deux coupures totales des opérations Git (janvier, novembre), retards d'Actions touchant 47 % des runs (juin), dégradations des push/PR (août, octobre).

Forgejo est le candidat de migration (auto-hébergeable, AGPL, API compatible Gitea). Lacunes connues :

• Pas de merge queue native. Seul l'auto-merge par PR — deux PRs vertes individuellement peuvent casser main ensemble. Réponse communautaire : outillage externe (shunt).
• API de protection de branches admin-only, ce qui complique les bots.
• Forgejo Actions compatible workflow, mais runners hors Linux, OIDC et LFS non vérifiés.

Étude du couplage

Inventaire du dépôt : 16 workflows, merge queue consommée via merge_group (workflow-merge-queue.yml), release-please (hotfixes séparés), images sur GHCR, Issues + Discussions + Projects actifs.

• Merge queue : seule vraie perte fonctionnelle, merge_group n'existe pas côté Forgejo.
• GHCR : mécanique à réécrire, pas une perte.
• release-please : reste exécutable sous Forgejo Actions, ou git-cliff.
• Projects : pas d'équivalent — labels + milestones.
• CI standard et templates : portables tels quels, surtout avec des runners auto-hébergés.

Questions ouvertes

1. Les taux d'incidents GitHub justifient-ils le coût de migration ?
2. Comment remplacer la merge queue : outillage externe, auto-merge par PR, ou contribution amont ?
3. Forgejo Actions suffit-il pour notre matrice CI (macOS, OIDC, gros artefacts, LFS) ?
4. Forme de la migration : bascule par repo, progressive, ou double-push miroir d'abord ?
5. Surfaces bloquantes : Dependabot, GHCR, Discussions, Projects ?