Aller au contenu
quest'n'click

ContribuerGuidePour contributeursS'applique de 4.4.0

Pull requests des bots

This page in EnglishCette page sur le wiki GitHub

Comment le mainteneur, ou un assistant qui travaille pour lui, traite les pull requests qu'ouvre Dependabot : quand, comment juger chacune, et que faire d'une rouge.

Ce que vous obtenez

Aucune pull request de bot laissée ouverte sans raison : chacune fusionnée au vert, corrigée et prise, ou fermée avec sa raison écrite, et la dépendance qu'elle fait bouger vérifiée partout où elle est recopiée (verrous des paquets, verrou Python du worker, épinglage des actions).

Contexte et versions

Le dépôt du moteur sur GitHub, wanoo/quest-n-click. .github/dependabot.yml en 4.4.0 : npm chaque semaine (mises à jour mineures et correctives regroupées sous minor-and-patch), GitHub Actions chaque semaine, pip (requirements.txt) chaque mois. Les versions majeures de @types/node sont ignorées : les types suivent la plus ancienne Node que le projet prend en charge (22.12, engines), et les types de Node 26 refusent du code juste sur la 22 (#101, 4.1.19) ; on les monte à la main quand engines bouge.

Prérequis

Où lancer les commandes

Les commandes gh n'importe où ; les vérifications dans le dépôt du moteur, sur une branche faite pour les mises à jour des bots.

Étapes

  1. Attendez que la release soit sortie. Les pull requests des bots se traitent après chaque release, jamais au milieu. release.yml exécute la copie de main de son workflow pendant qu'il publie un tag, et une mise à jour d'une action qu'il utilise changerait la publication en cours ; la release 4.1.19 a fait attendre ainsi #95–#102 (LOG #169).
  1. Listez-les, avec leurs vérifications.

    # n'importe où, avec gh connecté
    gh pr list -R wanoo/quest-n-click --author app/dependabot
    gh pr checks <number> -R wanoo/quest-n-click
  1. Fusionnez une pull request verte dont vous avez lu le changement (les notes de version de la dépendance, le diff du fichier de verrouillage). Plusieurs à la fois peuvent passer par une seule branche au lieu d'un cycle de CI chacune : fusionnez-y leurs commits, lancez la CI une fois, puis fermez chaque pull request du bot avec un renvoi vers la branche (LOG #169 en a traité sept ainsi).
  1. Une rouge se corrige ou se ferme, elle ne reste jamais. Reproduisez d'abord l'échec en local. Quand la mise à jour est juste et qu'un test ou notre code doit suivre, corrigez sur la branche (Playwright 1.64 faisait afficher à WebKit une erreur 500 volontaire d'un test, et le test PWA a appris à excuser exactement cette réponse). Quand la mise à jour ne convient pas au projet, fermez-la avec la raison écrite sur la pull request : Vite 8 (son bundler cassait un import par défaut CommonJS, le jeu ne démarrait pas), TypeScript 7 (plus de baseUrl, plus de paths non relatifs), des minimums pip relevés qui cassaient un Python partagé (NumPy 2.5), @types/node 26.
  1. Suivez les copies de la version. Certaines dépendances sont épinglées ailleurs aussi :
    • les verrous propres des paquets sous scripts/locks/ (le Bridge, les connecteurs, le Studio Server, l'image du Bridge) : lancez npm run locks quand une dépendance de ces paquets change, relisez le diff, committez-le ; npm run locks -- --check dit si chaque verrou convient encore ;
    • le verrou Python du worker du Studio, qui suit requirements.txt avec ses empreintes (Pillow 13.0.0, #213 : tests/worker-python-lock.test.ts) ;
    • l'épinglage d'une action : vérifiez le nouveau SHA contre le tag officiel (gh api repos/<owner>/<action>/git/ref/tags/<tag>).
  1. Une mise à jour d'une action qu'utilise release.yml ou candidate.yml n'est prouvée que par le candidat et la release suivants : étiquetez la branche full-ci (elle lance aussi le workflow candidat, à titre d'information) et dites dans la pull request ce qui reste à voir.

Résultat attendu, et comment le vérifier

gh pr list -R wanoo/quest-n-click --author app/dependabot ne liste rien, ou seulement des pull requests ouvertes depuis la dernière release. main est vert après les fusions.

Erreurs fréquentes

SymptômeCauseCorrection
Une PR de bot rouge seulement sur pwa-firefox ou une ligne WebKitUne instabilité connue (La CI expliquée)Relancez le job ; reproduisez avant d'accuser la mise à jour
tests/pack-locks.test.ts échoue après une fusionLe verrou d'un paquet sous scripts/locks/ ne convient plusnpm run locks, relisez, committez
Des erreurs de types après une majeure de @types/nodeDes types plus récents que la Node prise en chargeFermez-la ; dependabot.yml ignore déjà ces majeures

Fichiers ou données modifiés

package.json, package-lock.json, requirements.txt, .github/workflows/*.yml (épinglage des actions), scripts/locks/*.json, le verrou Python du worker. Un changement de code qui suit une mise à jour porte son fragment changes/ (Conventions).

Revenir en arrière

Une mise à jour fusionnée s'annule par une pull request qui annule son commit (git revert), avec la raison ; Dependabot la repropose ensuite, sauf si elle est ignorée dans .github/dependabot.yml.

Références