Dépannage des ensembles de règles
Si vous ne pouvez pas effectuer d’action dans un dépôt et que vous souhaitez savoir pourquoi, vous pouvez afficher les ensembles de règles actifs ciblant la branche ou l’étiquette avec laquelle vous travaillez. Pour plus d’informations, consultez « Gestion des ensembles de règles d’un dépôt ».
Selon les règles qui sont actives, vous devrez peut-être modifier votre historique de commit localement avant de pouvoir pousser vos commits vers la branche distante. Par exemple, si une branche nécessite que les commits soient signés, vous pouvez mettre à jour vos paramètres de signature, puis utiliser un rebasage interactif sur votre branche locale pour réécrire votre historique Git avec des commits signés. Pour plus d’informations, consultez « Règles disponibles pour les ensembles de règles » et « Utilisation du rebasage Git en ligne de commande ».
Si une branche ou une étiquette est ciblée par des règles limitant les métadonnées des commits, vos commits peuvent être rejetés si une partie des métadonnées des commits ne correspond pas à un certain modèle. Par exemple, vous devrez peut-être ajouter un numéro de problème au début de votre message de commit, ou changer le nom d’une nouvelle branche ou d’une nouvelle étiquette que vous essayez de pousser vers le dépôt. Si vos commits sont rejetés, vous voyez un message vous indiquant que le modèle auquel les métadonnées pertinentes doivent correspondre. Comme avec les commits signés, vous devrez peut-être effectuer un rebasage pour effectuer un squash des commits ou réécrire chaque commit individuellement. Pour plus d’informations, consultez « Règles disponibles pour les ensembles de règles ».
Lorsque vous utilisez des ensembles de règles push, un maximum de 1 000 mises à jour de référence sont autorisées par envoi ( push). Si votre envoi dépasse cette limite, il est rejeté. Pour plus d’informations, consultez Création d’un ensemble de règles pour un dépôt.
Dépannage des flux de travail des ensembles de règles
Les flux de travail des jeux de règles peuvent être configurés au niveau de l'organisation pour exiger que les flux de travail soient transférés avant de fusionner les demandes de tirage. Pour plus d’informations, consultez « Création des ensembles de règles pour les référentiels de votre organisation ».
Flux de travail de l’ensemble de règles pour les demandes de tirage ouvertes
Si vous créez une règle alors qu'une demande de tirage est ouverte, le flux de travail requis ne s'exécutera pas automatiquement. Pour déclencher le flux de travail requis, ajoutez un nouveau commit, mettez à jour votre branche, ou fermez et rouvrez la demande de tirage.
Événements de flux de travail de l'ensemble de règles pris en charge
Les flux de travail des jeux de règles prennent en charge l'utilisation de pull_request, pull_request_target, et d'événements merge_group. Par conséquent, vous devez spécifier un ou plusieurs de ces événements dans la section on: du flux de travail pour que le flux de travail soit exécuté par un jeu de règles.
Tous les filtres que vous spécifiez pour les événements pris en charge sont ignorés, par exemple, branches, branches-ignore, paths, types et ainsi de suite. Le flux de travail n'est déclenché, et est toujours déclenché, que par les types d'activité par défaut des événements pris en charge.
| Event | Types d’activités par défaut |
|---|---|
pull_request | opened, synchronize, reopened |
pull_request_target | opened, synchronize, reopened |
merge_group | checks_requested |
Pour plus d’informations, consultez « Événements qui déclenchent des flux de travail ».
Les flux de travail des ensembles de règles ne s'exécutent pas sur les événements déclenchés par GITHUB_TOKEN. Pour plus d’informations, consultez « Authentification par jeton automatique ».
Blocage de la création du référentiel
Un flux de travail requis peut empêcher la création d’un référentiel, car un flux de travail ne peut pas s'exécuter sur un référentiel initialisé. Pour contourner ce problème, l'ensemble de règles doit avoir « Évaluer » comme état de mise en œuvre, ou une personne disposant des autorisations de contournement doit créer le référentiel et contourner la protection des branches.
Pour plus d'informations sur les statuts de mise en œuvre et le mode « Évaluer », consultez Création d’un ensemble de règles pour un dépôt.
Pour plus d’informations sur les autorisations de contournement, consultez À propos des branches protégées.
Cibles de branche dans un ensemble de règles
Vérifiez que le flux de travail de votre ensemble de règles ne cible pas toutes les branches du référentiel. Il ne doit cibler que les branches pour lesquelles toutes les modifications sont effectuées par des demandes de tirage.
Répertoire pris en charge
Vérifiez que votre fichier de flux de travail existe dans le répertoire .github/workflows. Si vous souhaitez exécuter un flux de travail d'ensemble de règles sur des événements pull_request dans un référentiel qui n'est pas le référentiel source, vous pouvez effectuer l'une des actions suivantes :
- Ajoutez un conditionnel au fichier de flux de travail, tel que
if: true. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ». - Désactivez complètement les actions dans le référentiel source. Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».
- Désactivez le flux de travail individuel dans le référentiel source. Pour plus d’informations, consultez « Désactivation et activation d’un workflow ».
Utilisation du déclencheur merge_group
Si votre référentiel utilise GitHub Actions pour effectuer des vérifications requises ou si vous avez besoin de workflows via des ensembles de règles d’organisation sur les demandes de tirage dans votre référentiel, vous devez mettre à jour les workflows pour inclure l’événement merge_group en tant que déclencheur supplémentaire. Autrement, les vérifications d’état ne seront pas déclenchées lorsque vous ajouterez une demande de tirage à une file d’attente de fusion. La fusion échouera, car la vérification d’état requise ne sera pas signalée. L’événement merge_group est distinct des événements pull_request et push.
Autorisations du référentiel source
Vérifiez que les autorisations du référentiel source sont définies sur « Accessible à partir de référentiels dans l’organisation ORGANIZATION NAME ».
Pour plus d’informations, consultez « Gestion des paramètres de GitHub Actions pour un dépôt ».
Paramètres de confidentialité du référentiel source
Vérifiez que le fichier de flux de travail de l'ensemble de règles se trouve dans un référentiel source dont les paramètres de confidentialité sont identiques ou moins restrictifs que ceux des référentiels dans lesquels vous souhaitez l'exécuter. En clair, un flux de travail public peut s'exécuter sur n'importe quel référentiel de votre organisation, tandis qu'un flux de travail interne peut s'exécuter sur des référentiels internes et privés, et qu'un flux de travail privé peut s'exécuter sur des référentiels privés. Pour plus d’informations, consultez « À propos des workflows ».
Autorisations pour la création d’un référentiel
Pour créer un référentiel lorsqu’un flux de travail d’ensemble de règles est configuré, vérifiez que vous disposez d’autorisations de contournement pour votre ensemble de règles. Pour plus d’informations, consultez « Création d’un ensemble de règles pour un dépôt ».
Aperçus des règles
GitHub ne journalise pas les aperçus règles jusqu'à ce qu'une demande de tirage soit fusionnée ou qu'une fusion soit tentée.
Concurrence
Vérifiez que le flux de travail de votre ensemble de règles n'utilise pas le paramètre de concurrence cancel-in-progress. Pour en savoir plus sur la concurrence, consultez Contrôler la simultanéité des workflows et des tâches.