mcore-split-pr

À propos de mcore-split-pr

La compétence mcore-split-pr permet de diviser une grande demande de fusion Megatron-LM en plusieurs demandes plus petites, chacune concernant un nombre minimal de groupes d’experts CODEOWNERS. Elle résout un problème concret lié à la charge de révision : une demande de fusion couvrant les composants principaux, les exemples, les outils et les dossiers de formation implique de nombreux groupes d’experts, ce qui ralentit les fusionnements, tandis qu’une demande ciblant un seul dossier ne nécessite que les experts de ce dernier.

Le processus se déroule en trois phases. Tout d’abord, il analyse la demande de fusion en récupérant ses détails ainsi que les statistiques de différences via gh CLI, en analysant le fichier .github/CODEOWNERS pour associer les motifs de fichiers aux groupes d’experts, et en comptant le nombre de groupes d’experts distincts requis pour cette demande. Ensuite, il propose une division des fichiers en fonction de leurs groupes CODEOWNERS, conserve les tests avec le code de production qu’ils valident, identifie les dépendances entre demandes (par exemple des symboles renommés dans une demande dont une autre dépend), s’assure que chaque demande résultante puisse être fusionnée indépendamment, et présente ce plan sous forme de tableau pour approbation par l’utilisateur. Enfin, et uniquement après approbation, il met en œuvre la division en créant des branches à partir du bon répertoire de base, en appliquant les modifications ciblées via git apply, en effectuant des commits, puis en poussant les modifications vers le fork de l’utilisateur. Il crée toujours les demandes de fusion en tant que brouillons, ne pousse jamais directement vers le répertoire principal, demande toujours l’accord de l’utilisateur avant toute fusion forcée, et attribue le crédit à l’auteur initial lorsque l’utilisateur actuel n’est pas l’auteur de la demande.

Les utilisateurs cibles sont les contributeurs et les mainteneurs de Megatron-LM qui doivent gérer des demandes de fusion très volumineuses et souhaitent réduire le nombre de groupes d’experts par demande, tout en garantissant que chaque demande divisée puisse être examinée et fusionnée indépendamment. Cette compétence peut être activée par l’utilisateur en fournissant l’URL ou le numéro de la demande de fusion.

FAQ

Quel problème résout la division d’une demande de fusion ?

Elle réduit le nombre de groupes d’experts CODEOWNERS nécessaires par demande, ce qui diminue la charge de révision. Chaque demande de fusion résultante doit néanmoins pouvoir être fusionnée et examinée indépendamment.

Pousse-t-elle directement dans le répertoire principal ?

Non. Elle crée toujours les demandes de fusion en tant que brouillons et les pousse vers le fork de l’utilisateur, jamais directement vers le répertoire principal. De plus, elle demande toujours l’accord de l’utilisateur avant toute fusion forcée qui réduirait la taille de la demande originale.

Comment sont gérés les tests lors de la division ?

Les fichiers de test accompagnent le code de production qu’ils valident. Cette compétence évite expressément de diviser les tests en une demande de fusion distincte uniquement dans le but de réduire le nombre d’experts.

Que se passe-t-il si une demande de fusion divisée dépend d’une autre ?

Elle indique explicitement cette dépendance et ajoute des alias compatibles avec les versions antérieures, des réexportations ou des modules de substitution dans la première demande, afin que les demandes suivantes puissent en dépendre. Elle précise également l’ordre de fusion requis.

Quelles sont les conditions nécessaires à son exécution ?

Une interface gh CLI authentifiée pour le répertoire, un dépôt local connecté au répertoire distant principal, ainsi qu’un fork personnel vers lequel pousser les branches. Elle attend l’approbation de l’utilisateur avant d’exécuter la division.

Tous les fichiers

5 fichiersSKILL.md4,4 KBAfficherskill.oms.sig4,5 KBAfficherBENCHMARK.md2,7 KBAfficherevals/evals.json0,0 KBAfficherskill-card.md2,4 KBAfficher