À propos des ensembles de règles

À propos des ensembles de règles

Un ensemble de règles est une liste nommée de règles qui s’applique à un dépôt, ou à plusieurs dépôts d’une organisation. Vous pouvez créer des ensembles de règles pour contrôler la façon dont les personnes peuvent interagir avec une sélection de branches et d’étiquettes dans un dépôt. 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. Par exemple, vous pouvez configurer un ensemble de règles pour la branche feature de votre dépôt qui exige des commits signés et bloque les poussées forcées de tous les utilisateurs, à l’exception des administrateurs de dépôt.

Pour chaque ensemble de règles que vous créez, vous spécifiez les branches ou étiquettes de votre dépôt, ou les dépôts de votre organisation, auxquels l’ensemble de règles s’applique. Vous pouvez utiliser la syntaxe fnmatch pour définir un modèle visant à cibler des branches, étiquettes et dépôts. Par exemple, vous pouvez utiliser le modèle releases/**/* pour cibler toutes les branches de votre dépôt dont le nom commence par la chaîne releases/. Pour plus d’informations sur la syntaxe fnmatch, consultez « Création d’un ensemble de règles pour un dépôt ».

Lorsque vous créez un ensemble de règles, vous pouvez autoriser certains utilisateurs à contourner les règles de l’ensemble de règles. Il peut s’agir d’utilisateurs disposant d’un certain rôle, comme administrateur de dépôt, d’équipes spécifiques ou d’GitHub Apps.

Il existe une limite de 75 ensembles de règles par référentiel, et 75 ensembles de règles à l'échelle de l'organisation.

À propos des ensembles de règles, des branches protégées et des étiquettes protégées

Les ensembles de règles fonctionnent avec toutes les règles de protection de branches et règles de protection d’étiquettes d’un dépôt. La plupart des règles que vous pouvez définir dans les ensembles de règles sont similaires aux règles de protection, et vous pouvez commencer à utiliser des ensembles de règles sans remplacer l’une de vos règles de protection existantes.

En outre, vous pouvez importer des règles de protection des balises existantes dans des ensembles de règles de référentiel. Cette action implémente les mêmes protections de balise que celles que vous avez actuellement pour votre référentiel. Pour plus d’informations, consultez « Configuration de règles de protection d’étiquettes ».

Les ensembles de règles présentent les avantages suivants par rapport aux règles de protection de branches et d’étiquettes.

• Contrairement aux règles de protection, plusieurs ensembles de règles peuvent s’appliquer en même temps. Vous pouvez donc être sûr que chaque règle ciblant une branche ou une étiquette de votre dépôt est évaluée quand une personne interagit avec cette branche ou cette étiquette. Pour plus d’informations, consultez « À propos de la superposition de règles ».
• Les ensembles de règles ont des états, ce qui vous permet de gérer facilement les ensembles de règles actifs d’un dépôt sans avoir à en supprimer.
• Toute personne disposant d’un accès en lecture à un dépôt peut voir les ensembles de règles actifs du dépôt. Cela signifie qu’un développeur peut comprendre pourquoi il ne satisfait pas une règle, ou qu’un auditeur peut vérifier les contraintes de sécurité du dépôt, sans avoir besoin d’un accès administrateur au dépôt.

De plus, pour les organisations avec un plan GitHub Enterprise, vous pouvez effectuer les opérations suivantes avec des ensembles de règles.

• Configurer rapidement des ensembles de règles au niveau de l’organisation pour cibler plusieurs dépôts de votre organisation. Pour plus d’informations, consultez « Gestion des ensembles de règles pour les dépôts de votre organisation ».
• Créer des règles supplémentaires pour contrôler les métadonnées des commits entrant dans un dépôt, telles que le message de commit et l’adresse e-mail de l’auteur. Pour plus d’informations, consultez « Règles disponibles pour les ensembles de règles ».
• Utiliser un état « Évaluer » pour tester un ensemble de règles avant de le rendre actif et utiliser une page d’informations pour voir quelles actions utilisateur sont affectées par les règles. Pour plus d’informations, consultez « Gestion des ensembles de règles d’un dépôt ».

À propos de la superposition de règles

Un ensemble de règles n’a aucune priorité. Au lieu de cela, si plusieurs ensembles de règles ciblent la même branche ou la même étiquette dans un dépôt, les règles de chacun de ces ensembles de règles sont agrégées. Si la même règle est définie de différentes manières dans les ensembles de règles agrégés, la version la plus restrictive de la règle s’applique. En plus de pouvoir être superposés entre eux, les ensembles de règles peuvent aussi être superposés à des règles de protection ciblant la même branche ou la même étiquette.

Par exemple, examinez la situation suivante pour la branche my-feature du dépôt octo-org/octo-repo.

• Un administrateur du dépôt a configuré un ensemble de règles ciblant la branche my-feature. Cet ensemble de règles exige des commits signés et trois révisions sur les demandes de tirage avant qu’elles ne puissent être fusionnées.
• Une règle de protection de branche existante pour la branche my-feature exige un historique de commits linéaire et deux révisions sur les demandes de tirage avant que celles-ci ne puissent être fusionnées.
• Un administrateur de l’organisation octo-org a également configuré un ensemble de règles ciblant la branche my-feature du dépôt octo-repo. L’ensemble de règles bloque les poussées forcées et exige une révision sur les demandes de tirage avant qu’elles ne puissent être fusionnées.

Les règles de chaque source sont agrégées et toutes les règles s’appliquent. Lorsqu’il existe plusieurs versions différentes de la même règle, la version la plus restrictive de la règle s’applique. Par conséquent, la branche my-feature exige des commits signés et un historique de commits linéaire, les poussées forcées sont bloquées, et les demandes de tirage ciblant la branche exigent trois révisions avant de pouvoir être fusionnées.