Création des ensembles de règles pour les référentiels de votre organisation

Dans cet article

Vous pouvez créer un ensemble de règles pour cibler plusieurs dépôts de votre organisation.

Qui peut utiliser cette fonctionnalité

Organization owners can create rulesets at the organization level.

Présentation

Vous pouvez créer des ensembles de règles dans votre organisation pour contrôler la façon dont les utilisateurs peuvent interagir avec les dépôts de votre organisation. Vous pouvez contrôler par exemple qui peut pousser les commits vers une certaine branche, la façon dont les commits doivent être mis en forme, ou qui peut supprimer ou renommer une étiquette. Vous pouvez également empêcher les utilisateurs de renommer les dépôts.

Lorsque vous créez un ensemble de règles pour une organisation, vous utilisez la syntaxe fnmatch pour définir quels dépôts de votre organisation, et quelles branches ou étiquettes de ces dépôts, sont ciblés par l’ensemble de règles. Cela permet de cibler plus rapidement les référentiels de votre organisation que de créer un ensemble de règles distinct pour chaque référentiel. Pour plus d’informations, consultez « À propos des modèles fnmatch pour les branches, les balises et les référentiels ».

Les duplications n’héritent pas des ensembles de règles de leurs dépôts amont. Toutefois, les duplications appartenant à votre organisation sont soumises aux ensembles de règles que vous créez, comme tout autre dépôt.

Vous pouvez importer un ensemble de règles à partir d’un autre référentiel ou d’une autre organisation à l’aide d’un fichier JSON. Ceci peut être utile si vous souhaitez appliquer le même ensemble de règles à plusieurs référentiels ou organisations. Pour plus d’informations, consultez « Gestion des ensembles de règles pour les dépôts de votre organisation ».

Pour créer un ensemble de règles, suivez la procédure suivante :

Création d’un ensemble de règles de branche ou de balise

  1. Dans l’angle supérieur droit de GitHub.com, sélectionnez votre photo de profil, puis sur Vos organisations.

    Capture d’écran du menu déroulant sous l’image de profil de @octocat. « Vos organisations » est présenté en orange foncé.

  2. En regard de l’organisation, cliquez sur Paramètres.

  3. Dans la barre latérale gauche, dans la section « Code, planification et automatisation », cliquez sur Dépôt, puis sur Ensembles de règles de dépôt.

    Capture d’écran de la page des paramètres d’une organisation. Dans la barre latérale, un lien intitulé « Ensembles de règles de dépôt » est encadré en orange.

  4. Vous pouvez créer un ensemble de règles ciblant des branches ou un ensemble de règles ciblant des étiquettes.

    • Pour créer un ensemble de règles ciblant des branches, cliquez sur Nouvel ensemble de règles de branche.

    • Pour créer un ensemble de règles ciblant des étiquettes, sélectionnez , puis cliquez sur Nouvel ensemble de règles d’étiquette.

      Capture d’écran de la page « Ensembles de règles ». À côté du bouton « Nouvel ensemble de règles de branche », un menu déroulant est développé, avec une option intitulée « Nouvel ensemble de règles d’étiquette » encadrée en orange.

  5. Dans la section « Général », entrez un nom pour l’ensemble de règles, puis sélectionnez Désactivé et cliquez sur l’un des états d’application suivants :

    • Actif : votre ensemble de règles sera appliqué lors de la création.
    • Évaluer : votre ensemble de règles ne sera pas appliqué, mais vous serez en mesure de surveiller les actions qui violent ou non les règles sur la page « Informations sur les règles ». Pour plus d’informations, consultez « Consultation des informations sur les ensembles de règles ».
    • Désactivé : votre ensemble de règles n’est pas appliqué or evaluated.

Octroi d’autorisations de contournement pour votre ensemble de règles

Vous pouvez accorder certains rôles, équipes ou applications des autorisations de contournement pour votre ensemble de règles. Les rôles suivants peuvent bénéficier d’un accès de contournement :

  • Administrateurs de référentiels ou propriétaires d’organisations
  • Le rôle de maintenance ou d’écriture, ou rôles de référentiel personnalisés en fonction du rôle d’écriture
  • Teams
  • GitHub Apps

  1. Pour accorder des autorisations de contournement pour l’ensemble de règles, dans la section « Liste de contournement », cliquez sur Ajouter un contournement.

  2. Dans la boîte de dialogue modale « Ajouter un contournement » qui s’affiche, recherchez le rôle, l’équipe ou l’application à laquelle vous souhaitez accorder des autorisations de contournement, puis sélectionnez le rôle, l’équipe ou l’application dans la section « Suggestions » et cliquez sur Ajouter sélectionné.

  3. Si vous le souhaitez, pour accorder un contournement à un acteur sans lui permettre d’envoyer directement vers un référentiel, sélectionnez Toujours , puis cliquez sur Pour les demandes de tirage (pull requests) uniquement.

    L’acteur sélectionné est maintenant tenu d’ouvrir une demande de tirage (pull request) pour apporter des modifications à un référentiel, créant une trace numérique claire avec ses modifications. L’acteur peut ensuite choisir de contourner les protections de branche et de fusionner cette demande de tirage (pull request).

Choix des référentiels à cibler dans votre organisation

Avec votre ensemble de règles, vous pouvez choisir de cibler tous les référentiels de votre organisation, les référentiels de votre organisation qui correspondent à une certaine convention d’affectation de noms ou une liste de référentiels sélectionnés manuellement dans votre organisation.

Si un dépôt est ciblé par un ensemble de règles créé au niveau de l’organisation, seuls les propriétaires de l’organisation peuvent modifier l’ensemble de règles. Toutefois, les personnes disposant d’un accès administrateur au dépôt, ou disposant d’un rôle personnalisé comprenant l’autorisation « modifier les règles de dépôt », peuvent créer des ensembles de règles supplémentaires au niveau du dépôt. Les règles de ces ensembles de règles seront agrégées avec les règles définies au niveau de l’organisation. Conséquence, la création d’un nouvel ensemble de règles peut rendre les règles ciblant une branche ou une étiquette plus restrictives, mais jamais moins restrictives. Pour plus d’informations sur la création des ensembles de règles, consultez « À propos des ensembles de règles ».

Ciblage de tous les référentiels de votre organisation

Pour cibler tous les référentiels de votre organisation, dans la section « Référentiels cibles », sélectionnez Cible : RÉFÉRENTIEL, puis cliquez sur Tous les référentiels.

Ciblage de référentiels par convention d’affectation de noms dans votre organisation

  1. Pour cibler une liste dynamique de référentiels dans votre organisation par convention d’affectation de noms, dans la section « Référentiels cibles », sélectionnez Cible : RÉFÉRENTIEL, puis cliquez sur Liste dynamique de référentiels.

  2. Pour commencer à définir un modèle de ciblage, dans la section « Critères de ciblage », sélectionnez Ajouter une cible , puis cliquez sur Inclure par modèle ou Exclure par modèle.

  3. Dans la boîte de dialogue modale qui s’affiche, entrez un modèle de nommage de référentiel à l’aide de la syntaxe fnmatch, puis cliquez sur Ajouter un modèle d’inclusion ou Ajouter un modèle d’exclusion. Pour plus d’informations sur la syntaxe fnmatch, consultez « Utilisation de la fnmatchsyntaxe ».

    Remarque : vous pouvez ajouter plusieurs critères de ciblage au même ensemble de règles. Par exemple, vous pouvez inclure tous les dépôts correspondant au modèle *cat*, puis exclure spécifiquement un dépôt correspondant au modèle not-a-cat.

  4. Si vous le souhaitez, dans la page de configuration de l’ensemble de règles, sélectionnez Empêcher le renommage des référentiels cibles.

Ciblage des référentiels de votre organisation par propriétés

**Remarque : ** Les propriétés du référentiel sont en version bêta publique et susceptibles d’être modifiées.

Vous pouvez cibler des référentiels de votre organisation par des propriétés personnalisées. Pour plus d’informations, consultez « Gestion des propriétés personnalisées pour les référentiels de votre organisation ».

  1. Pour cibler une liste dynamique de référentiels dans votre organisation par propriétés, dans la section « Référentiels cibles », sélectionnez Cible : RÉFÉRENTIEL, puis cliquez sur Liste dynamique par propriété.
  2. Pour ajouter une cible, dans la section « Critères de ciblage », sélectionnez Ajouter une cible , puis cliquez sur Inclure par propriété ou Exclure par propriété.
  3. Dans la boîte de dialogue modale qui s’affiche, sélectionnez une propriété dans le menu déroulant, puis sélectionnez une valeur pour la propriété.
  4. Cliquez sur Ajouter une cible.

Ciblage de référentiels sélectionnés dans votre organisation

  1. Pour cibler une liste statique de référentiels sélectionnés manuellement dans votre organisation, dans la section « Référentiels cibles », sélectionnez Cible : RÉFÉRENTIEL, puis cliquez sur Sélectionner les référentiels.
  2. Pour sélectionner les référentiels à cibler, dans la section « Critères de ciblage », sélectionnez Sélectionnez les référentiels, puis recherchez le nom de chaque référentiel que vous souhaitez cibler. Sélectionnez chaque référentiel dans les résultats de la recherche.

Choix des branches ou des balises à cibler

Pour cibler les branches ou les balises, dans la section « Cibler des branches » ou « Cibler des balises », sélectionnez Ajouter une cible, puis sélectionnez la façon dont vous souhaitez inclure ou exclure des branches ou des étiquettes. Vous pouvez utiliser la syntaxe fnmatch pour inclure ou exclure des branches ou des étiquettes sur la base d’un modèle. Pour plus d’informations, consultez « Utilisation de la syntaxe fnmatch ».

Vous pouvez ajouter plusieurs critères de ciblage au même ensemble de règles. Par exemple, vous pouvez inclure la branche par défaut, inclure toutes les branches correspondant au modèle *feature*, puis exclure spécifiquement une branche correspondant au modèle not-a-feature.

Sélection de protections de branche ou de balise

Dans la section « Protections de branches » ou « Protections d’étiquettes », sélectionnez les règles que vous souhaitez inclure dans l’ensemble de règles. Lorsque vous sélectionnez une règle, vous pouvez entrer des paramètres supplémentaires pour la règle. Pour plus d’informations sur les règles, consultez « Règles disponibles pour les ensembles de règles ».

Remarques : si vous sélectionnez Exiger des vérifications d'état avant la fusion, dans la section « Paramètres supplémentaires » :

  • Vous pouvez entrer le nom de chaque vérification d’état que vous souhaitez exiger. Pour terminer l’ajout de la vérification d’état comme condition requise, vous devez cliquer sur .
  • Si vous sélectionnez Exiger que les branches soient à jour avant la fusion, vous devez définir une vérification pour que la protection prenne effet.

Ajout de restrictions des métadonnées

Remarques :

  • L’ajout de restrictions de métadonnées peut avoir un impact sur l’expérience des personnes qui contribuent à votre référentiel. Avant d’appliquer un ensemble de règles avec des restrictions de métadonnées, vous pouvez sélectionner l’état d’application « Évaluer » pour votre ensemble de règles afin de tester les effets des restrictions de métadonnées sans affecter les contributeurs. Pour plus d’informations sur les restrictions de métadonnées, consultez « Règles disponibles pour les ensembles de règles ».
  • Les restrictions de métadonnées sont destinées à accroître la cohérence entre les commits de votre dépôt. Elles ne sont pas destinées à remplacer les mesures de sécurité, comme exiger une révision du code via des demandes de tirage.
  • Si vous effectuez la fusion Squash d’une branche, toutes les validations sur cette branche doivent répondre à toutes les exigences de métadonnées pour la branche de base.

  1. Si vous le souhaitez, dans la section « Restrictions des métadonnées », pour ajouter une règle permettant de contrôler les métadonnées des commits poussés vers la branche ou l’étiquette, cliquez sur .

    Capture d’écran de la section « Restriction des métadonnées ». À droite de l’en-tête, une icône plus est mise en évidence avec un encadré orange.

  2. Configurez les paramètres de la règle de restriction des métadonnées, puis cliquez sur Ajouter. Vous pouvez ajouter plusieurs restrictions au même ensemble de règles.

    Pour la plupart des conditions, telles que « Doit commencer par un modèle de correspondance », le modèle que vous entrez est interprété littéralement et les caractères génériques ne sont pas pris en charge. Par exemple, le caractère * représente uniquement le caractère * littéral.

    Pour les modèles plus complexes, vous pouvez sélectionner « Doit correspondre à un modèle regex donné » ou « Ne doit pas correspondre à un modèle regex donné », puis utiliser la syntaxe d’expression régulière pour définir le modèle correspondant. Pour plus d’informations, consultez « Utilisation d’expressions régulières pour les métadonnées de commit ».

    Toute personne visualisant les ensembles de règles d’un dépôt peut voir la description que vous fournissez.

Finalisation de votre ensemble de règles et étapes suivantes

Pour terminer la création de votre ensemble de règles, cliquez sur Créer. Si le statut de l’application de l’ensemble de règles est défini sur « Actif », l’ensemble de règles prend effet immédiatement.

Vous pouvez afficher des aperçus pour l’ensemble de règles pour voir comment les règles affectent vos collaborateurs. Si le statut de l’application est défini sur « Évaluer », vous pouvez voir quelles actions auraient réussi ou échoué si l’ensemble de règles était actif. Pour plus d’informations sur les aperçus des ensemble de règles, voir « Gestion des ensembles de règles d’un dépôt ».

À propos des modèles fnmatch pour les branches, les balises et les référentiels

Vous pouvez utiliser la syntaxe fnmatch pour définir des modèles visant à cibler les noms des branches, étiquettes et dépôts lorsque vous créez un ensemble de règles.

Vous pouvez utiliser le caractère générique * pour faire correspondre n’importe quelle chaîne de caractères. Étant donné que GitHub utilise l’indicateur File::FNM_PATHNAME pour la syntaxe File.fnmatch, le caractère générique * ne correspond pas aux séparateurs de répertoires (/). Par exemple, qa/* correspond à toutes les branches commençant par qa/ et contenant une barre oblique unique, mais ne correspond pas à qa/foo/bar. Vous pouvez inclure n’importe quel nombre de barres obliques après qa avec qa/**/*, qui correspondrait, par exemple, à qa/foo/bar/foobar/hello-world. Vous pouvez également étendre la chaîne qa avec qa**/**/* pour rendre la règle plus inclusive.

Pour plus d’informations sur les options de syntaxe, consultez la documentation fnmatch.

Remarque : bien que GitHub prend en charge File::FNM_PATHNAME dans la syntaxe fnmatch, File::FNM_EXTGLOB n’est pas pris en charge.

À propos des expressions régulières pour les métadonnées de commit

Lorsque vous ajoutez des restrictions de métadonnées, vous pouvez utiliser la syntaxe d’expression régulière pour définir des modèles auxquels les métadonnées pertinentes, telles que le message de commit ou le nom de la branche ou de l’étiquette, doivent ou ne doivent pas correspondre.

Les ensembles de règles prennent en charge la syntaxe RE2. Pour plus d’informations, consultez le Guide de la syntaxe de Google. Pour valider vos expressions, vous pouvez utiliser le validateur sur regex101.com en sélectionnant la saveur « Golang » dans la barre latérale gauche.

Par défaut, les expressions régulières dans les restrictions de métadonnées ne prennent pas en compte plusieurs lignes de texte. Par exemple, si vous avez un message de validation multiligne, le modèle ^ABC est une correspondance si une ligne du message commence par ABC. Pour correspondre à plusieurs lignes du message, commencez votre expression par (?m).

L’assertion avant négative, représentée par ?!, n’est pas prise en charge. Toutefois, dans les cas où vous devez rechercher une chaîne donnée qui n’est pas suivie d’une autre chaîne donnée, vous pouvez utiliser l’assertion avant positive, représentée par ?, combinée à la condition « Ne doit pas correspondre à un modèle regex donné ».

Remarque : Si vous exigez que les contributeurs valident les commits, cela peut interférer avec vos modèles d’expression régulière. Quand une personne procède à une validation, GitHub ajoute une chaîne comme Signed-off-by: #AUTHOR-NAME <#AUTHOR-EMAIL> au message de commit. Pour plus d’informations, consultez « Gestion de la stratégie de validation de commits pour votre organisation ».

Modèles d’expressions régulières utiles

Les exemples suivants fournissent des modèles utiles pour les métadonnées de commit. Pour utiliser ces modèles, définissez Condition requise sur « Doit correspondre à un modèle d’expression régulière donné ».

Vérifier que les noms de branche sont compatibles avec Windows

Vous pouvez utiliser le modèle suivant pour vous assurer que les noms de branche comprennent uniquement des nombres, des lettres minuscules et les caractères - et _. Cela garantit que les noms de branche sont compatibles avec les systèmes d’exploitation qui n’utilisent pas de systèmes de fichiers sensibles à la casse par défaut.

Text
\A[0-9a-z-_]$

Correspond à : my-branch

Ne correspond pas à : myBranch

Vérifier que les noms d’étiquette utilisent une gestion de versions sémantique

Vous pouvez utiliser le modèle suivant pour vous assurer que les noms d’étiquette sont conformes à une gestion de versions sémantique. Pour plus d’informations, consultez la documentation sur semver.org.

Text
^(0|[1-9]\d*)\.(0|[1-9]\d*)\.(0|[1-9]\d*)(?:-((?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*)(?:\.(?:0|[1-9]\d*|\d*[a-zA-Z-][0-9a-zA-Z-]*))*))?(?:\+([0-9a-zA-Z-]+(?:\.[0-9a-zA-Z-]+)*))?$

Correspond à : 1.2.3, 10.20.30, 1.1.2-prerelease+meta

Ne correspond pas à : 1.2, 1.2-SNAPSHOT

Limiter la longueur des lignes dans les messages de commit

Le livre Pro Git recommande de limiter la première ligne d’un message de commit à environ 50 caractères.

Vous pouvez utiliser le modèle suivant pour vous assurer que la première ligne d’un message de commit contient 50 caractères ou moins.

Text
\A.{1,50}$
Vérifier que les messages de commit commencent par une résolution et un numéro de problème

Vous pouvez utiliser le modèle suivant pour vous assurer que les messages de commit contiennent le mot Resolves: ou Fixes:, suivi d’une chaîne telle que #1234.

Text
^(Resolves|Fixes): \#[0-9]+$

Correspond à : Fixes: #1234

Ne correspond pas à : Add conditional logic to foo.bar

Appliquer des commits conventionnels

Vous pouvez utiliser le modèle suivant pour vous assurer que les messages de commit sont conformes à la spécification relative aux commits conventionnels. Pour plus d’informations, consultez conventionalcommits.org.

Text
^(build|chore|ci|docs|feat|fix|perf|refactor|revert|style|test){1}(\([\w\-\.]+\))?(!)?: ([\w ])+([\s\S]*)

Correspond à : feat: allow provided config object to extend other configs

Ne correspond pas à : Add conditional logic to foo.bar