CI pour les stacks ghstack

Maintiens une utilisation faible de CI en l'exécutant là où ses résultats peuvent guider le travail actuel. Marque explicitement les PRs différées avec le préfixe [no-ci] dans le titre, et retire-le quand leurs résultats deviennent utiles. Respecte les préférences CI explicites de l'utilisateur.

Utilise l'orthographe exacte [no-ci] décrite dans Skip CI while iterating.

Choisir où exécuter CI

• Exécute CI sur les PRs en préparation pour review ou atterrissage, ou quand ses résultats sont nécessaires pour diagnostiquer une défaillance ou valider une modification sur une plateforme CI-only.
• Exécute CI sur une PR supérieure quand elle fournit la couverture d'intégration nécessaire pour plusieurs modifications ensemble. La position dans la stack seule n'est pas une raison de la différer.
• Envisage de différer les PRs spéculatives ou qui changent rapidement dont les résultats n'affecteront pas la prochaine décision, ou les PRs supérieures attendant un correctif connu de la stack inférieure. Garde CI activée partout où elle est nécessaire pour enquêter sur ce correctif.

Pour les stacks plus longues que cinq PRs, les cinq du bas constituent un bon point de départ quand tu te prépares à atterrir par le bas : envisage de différer les PRs supérieures jusqu'à ce que leurs résultats soient nécessaires. Cinq est une indication pour limiter les exécutions CI répétées durant l'itération, pas un quota ou un plafond. Utilise moins ou plus selon les besoins du travail. Par exemple, dans une stack A à H, CI pourrait être utile sur A à E tandis que F à H sont encore spéculatifs. Active G aussi si ses résultats d'intégration sont nécessaires maintenant ; après que A et B atterrissent, réévalue F à H au lieu d'activer automatiquement un nombre fixe de PRs.

Avant les écritures ou reruns de workflow GitHub, suis CLAUDE.md et AI_POLICY.md. Affiche les numéros de PR exacts, les anciens/nouveaux titres et les runs à relancer, et obtiens l'approbation explicite de toute action non déjà approuvée. L'approbation existante pour ces modifications exactes n'a pas besoin d'être répétée.

Soumettre ou mettre à jour une stack

1. Identifie la stack complète dans l'ordre de dépendance, de bas en haut, y compris les commits qui deviendront de nouvelles PRs. Utilise l'ascendance des commits et les trailers Pull-Request, et actualise les titres et états des PRs existantes avec gh. Exclue les modifications atterries. GitHub peut afficher une PR ghstack comme fermée après son atterrissage ; confirme l'atterrissage sur main plutôt que de te fier uniquement à l'état MERGED.
2. Choisis les PRs dont les résultats sont utiles maintenant. Préfixe les autres titres avec [no-ci], par exemple [no-ci] Add another operator. Préserve le reste de chaque titre et évite d'ajouter le préfixe deux fois. Enregistre les numéros de PR et les raisons de leur déférence dans les notes de tâche.
3. Avant de créer de nouvelles PRs avec ghstack, mets le préfixe dans les sujets de commit pour les PRs différées. Le titre initial de la PR provient du sujet, donc le définir seulement après la création peut laisser démarrer CI.
4. Pour les PRs existantes, ajoute ou retire le préfixe dans à la fois le titre de PR live et le sujet de commit correspondant avant de soumettre les mises à jour. Les soumissions ghstack ordinaires préservent les titres GitHub ; ghstack -u les remplace à partir des sujets de commit. Garde leur état de préfixe cohérent pour qu'un ghstack -u ultérieur ne puisse pas annuler la décision CI. Quand tu reformules un commit, lis et préserve ses trailers Pull-Request: et ghstack-source-id: actuels, et suis les règles de soumission du repository.

Ajouter [no-ci] n'annule pas CI qui est déjà en cours d'exécution.

Activer CI et faire avancer la stack

Après mises à jour, restacks, réordres, ou atterrissages de PRs inférieures, actualise la stack et réévalue où CI est utile. Pour activer une PR, retire le préfixe initial et son espace séparant du titre de PR live et du sujet de commit. Préserve les demandes explicites de l'utilisateur de différer CI. Si l'origine ou l'objectif d'un préfixe est inconnu dans le contexte actuel, demande avant de le retirer à moins que l'utilisateur ait déjà explicitement autorisé l'activation de CI pour cette PR. N'suppose pas que les notes de tâche d'une session antérieure sont disponibles.

Active CI après retrait du préfixe de titre : pousse une mise à jour réelle avec ghstack, ou relance les derniers workflows qui ont échoué à la porte [no-ci] pour le head actuel de cette PR. Une simple édition de titre ne démarre pas CI.

Définissez pr_number à la PR sélectionnée et inspecte ses checks actuels :

gh pr checks "$pr_number" --repo pytorch/pytorch --json name,state,workflow,link,bucket,completedAt

Définissez check_link au lien Actions link d'une porte échouée candidate. Pour un lien avec le chemin /pytorch/pytorch/actions/runs/12345/job/67890, l'ID de run est 12345. Extrais-le et inspecte le run :

run_id="${check_link#*/actions/runs/}"
run_id="${run_id%%/*}"
gh pr view "$pr_number" --repo pytorch/pytorch --json headRefOid
gh run view "$run_id" --repo pytorch/pytorch --json headSha,conclusion,jobs
gh run view "$run_id" --repo pytorch/pytorch --log-failed

Confirme que headSha du run correspond à headRefOid de la PR et que ses logs affichent une défaillance à la porte [no-ci]. Relance chaque ID de run distinct sélectionné une fois avec gh run rerun "$run_id" --repo pytorch/pytorch ; plusieurs checks peuvent appartenir au même run. Évite les heads obsolètes et les défaillances sans lien. Enregistre les PRs activées et différées mises à jour dans les notes de tâche quand tu as terminé.

Avant l'atterrissage

Active CI pour chaque PR ouverte incluse dans l'atterrissage, y compris les dépendances inférieures. Retire [no-ci] de leurs titres de PR live et sujets de commit, et attends que les checks requis passent sur leurs heads actuels avant de demander la fusion. Le préfixe échoue intentionnellement à une porte de blocage de fusion, et le titre de PR live devient le sujet du commit atterri. CI sur une PR supérieure ne remplace pas les checks requis sur les PRs inférieures en cours d'atterrissage.