[GH-P4] Checks API, statuts, GitHub Deployments + relance sur le SHA demandé

[bobdivx]

[GH-P4] Checks API, statuts de commit, GitHub Deployments + relance sur le SHA demandé

Plan : devforge-plan-github-app.md, phase P4. S'appuie sur P0–P3.

Checklist

• P4-01 crates/github/src/checks.rs (RepoApi) : create_check_run (name = "DevForge / deploy", head_sha, details_url, external_id = deployment_uuid), update_check_run(id, status, conclusion, output{title, summary, text}), repli POST /repos/{o}/{r}/statuses/{sha} (context devforge/deploy) pour les projets en PAT, branch_head, parse_repo. Le token est masqué en Debug ; les erreurs ne contiennent que le code HTTP.

• P4-02 Branché dans routes::run_real_deploy_at, par où passent tous les déploiements prod (manuel, webhook historique, webhook app-level, poller auto-deploy) :

  • enfilé ⇒ queued ;
  • build démarré (entrée dans le slot du nœud) ⇒ in_progress ;
  • succès ⇒ success + details_url vers la page du déploiement DevForge + résumé avec l'URL ;
  • échec ⇒ failure : titre lisible via error_parser, 50 dernières lignes masquées (valeurs d'env du projet + jetons x-access-token/ghs_/ghp_/github_pat_) ;
  • annulation / remplacement ⇒ cancelled.

  Statuts PAT : pending → success/failure/error.

• P4-03 GitHub Deployments : POST /deployments (environment Production, auto_merge:false, required_contexts:[]) + deployment_statuses (in_progress → success avec environment_url = production_url / failure / inactive si annulé). C'est ce qui affiche « View deployment ».

• P4-04 Colonnes deployments.check_run_id, github_deployment_id, github_head_sha (ALTER dont l'échec est toléré). Les appels GitHub tournent dans des tâches détachées. Un échec est journalisé puis retenté une fois au bout de 20 s, et ne fait jamais échouer le déploiement.

• Relance au SHA exact (dette P3) : check_run/check_suite.rerequested ⇒ devforge_pin_sha = head_sha ⇒ run_real_deploy_at(.., Some(sha)) ⇒ DeployRequest.pin_sha ⇒ après la synchro de branche, git fetch origin <sha> && git reset --hard <sha>. Le SHA est validé (hex, 7–40 caractères) contre l'injection shell. Le Check Run vise ce même SHA.

Garde-fou (règle 3)

Rien n'est envoyé à GitHub sans mode App (DEVFORGE_GITHUB_APP=1 ou app enregistrée). Aujourd'hui, en prod, aucune app n'existe : zéro appel, comportement identique. En mode App : Checks API pour les projets liés à l'installation, statuts de commit pour les autres (PAT).

Tests

• github_checks_tests.rs (wiremock) :
  • machine d'états succès : check-runs queued → in_progress → completed/success, deployment + statuses in_progress/success ;
  • échec (conclusion failure, deployment failure) et annulation (cancelled / inactive) ;
  • PAT ⇒ statuts pending/pending/failure, aucun check run ;
  • panne réseau GitHub (502 / hôte injoignable) ⇒ 1 essai + 1 nouvel essai, pas de panique, déploiement non affecté.
• failure_output : aucun secret d'env du projet ni jeton GitHub dans output.text, 50 dernières lignes seulement.
• pin_sha_is_validated (deploy) ; la relance épingle bien devforge_pin_sha (events).
• parse_repo (URL https/ssh/owner/repo, rejets) et clip (coupe sans casser un caractère).
• Local : cargo test --workspace ⇒ 635 passés, 0 échec.

Validation (manuelle, après création de l'app en prod)

Commit sur main d'un repo installé ⇒ coche verte « DevForge / deploy » avec lien vers les logs. Build cassé volontairement ⇒ croix rouge avec un titre d'erreur lisible. Pas encore faite : il faut l'app en prod (P1) et un projet lié.

Risques

• Dès qu'une app est créée (mode App actif), les projets encore en PAT reçoivent aussi des statuts de commit et des GitHub Deployments via le PAT d'instance. C'est attendu par le plan, mais visible sur tous leurs dépôts.
• Le head_sha du Check Run vient de GET /commits/{branch} au moment de l'enfilage. Si la branche avance avant le clone, la coche peut viser le commit précédent. La relance, elle, est exacte grâce à l'épinglage.
• L'épinglage fait un git fetch origin <sha> : il faut que GitHub serve le commit par SHA (c'est le cas pour un commit atteignable). Sous Windows, on déploie la tête de branche, avec un log.
• L'environnement dev (dev_env.rs) n'est pas suivi côté GitHub dans cette phase (les previews de PR arrivent en P5).