Dans cette unité, vous apprendrez à créer et gérer des ensembles de règles (rulesets) et à comprendre les avantages qu’ils offrent par rapport aux règles de protection traditionnelles.

En tant qu’administrateur GitHub, vous avez besoin d’un contrôle précis sur qui peut pousser, supprimer ou renommer des branches et des tags. Les ensembles de règles vous permettent de regrouper plusieurs règles sous un même nom, de les appliquer à des branches ou tags spécifiques, et de les activer ou désactiver sans les supprimer. Ils complètent les règles de protection existantes, offrant une approche unifiée et structurée de la sécurité des dépôts.

🔐 Qu’est-ce qu’un ensemble de règles ?

Un ensemble de règles est une collection nommée de règles qui s’appliquent à une ou plusieurs branches ou tags dans votre dépôt.

• Ciblage : choisissez des branches spécifiques (ex. : feature/*) ou des tags (ex. : v*.*)
• Définition des règles : exiger des vérifications de statut, imposer des commits signés, bloquer les push forcés, etc.
• Permissions de contournement : autoriser les administrateurs, équipes ou applications GitHub à contourner certaines règles

📌 Exemple : un ensemble de règles pour les branches feature/* peut exiger des commits signés et bloquer les push forcés pour tous sauf les administrateurs.

📊 Comparaison : règles de protection vs ensembles de règles

✅ Avantages clés des ensembles de règles

• Superposition : regrouper des règles de plusieurs sources ; le paramètre le plus strict s’applique
• Statuts : activer, désactiver ou tester les ensembles sans les supprimer
• Transparence : les développeurs et auditeurs peuvent consulter les règles actives sans droits d’administration

🚀 Créer votre premier ensemble de règles

1. Sur GitHub.com, allez dans Paramètres > Code et automatisation > Règles > Ensembles de règles
2. Cliquez sur Nouvel ensemble de règles, puis sélectionnez Branche ou Tag
3. Saisissez un nom et choisissez les branches ou tags ciblés
4. Activez les règles souhaitées (ex. : exiger des vérifications de statut, bloquer les push forcés)
5. Définissez les permissions de contournement (ex. : administrateurs, application CI)
6. Cliquez sur Créer

🔧 Gérer et modifier les ensembles de règles

• Afficher les ensembles actifs : sur la page des ensembles de règles, voyez quels ensembles ciblent une branche ou un tag donné
• Modifier un ensemble : cliquez sur son nom, ajustez les règles ou les cibles, puis enregistrez les modifications
• Changer le statut : activez ou désactivez un ensemble sans le supprimer
• Supprimer : retirez les ensembles obsolètes lorsqu’ils ne sont plus nécessaires

🛡️ Règles disponibles

Les ensembles de règles de dépôt prennent en charge de nombreuses protections similaires à celles des branches et des tags protégés.

Exemples courants :

• Exiger la réussite des vérifications de statut (ex. : CodeQL, revue des dépendances)
• Exiger des commits signés
• Bloquer les push forcés ou les suppressions
• Restreindre qui peut pousser ou fusionner

🧩 Superposition des ensembles de règles et des protections

GitHub agrège toutes les règles applicables — protection des branches, protection des tags et ensembles de règles multiples — et applique le paramètre le plus restrictif.

📌 Exemple : la branche my-feature a :

• Un ensemble de règles exigeant des commits signés et trois revues
• Une règle de protection de branche exigeant un historique linéaire et deux revues

➡️ Résultat : les pull requests nécessitent trois revues, et les commits doivent être signés et linéaires

⚖️ Impacts des politiques et ensembles de règles dans GitHub Enterprise

Vos politiques et ensembles de règles influencent la sécurité, la conformité, l’expérience développeur et l’efficacité opérationnelle. Il est essentiel de trouver le bon équilibre entre contrôle et flexibilité.

🔐 Sécurité et conformité

⚙️ Productivité des développeurs et efficacité des workflows

🛡️ Gouvernance et contrôle d’accès

🔄 CI/CD et automatisation

🔍 API de journal d’audit GitHub pour enquêter sur les actifs manquants

Les journaux d’audit permettent de suivre des événements comme la suppression de dépôts ou le retrait de membres. Utilisez REST ou GraphQL pour interroger et résoudre les problèmes.

🛠️ Étapes pour résoudre les actifs manquants

1. Identifier l’actif : ex. : repository.deleted
2. Interroger l’API Audit Log (REST) :

GET /orgs/{org}/audit-log?phrase=repository.deleted
Authorization: Bearer YOUR_TOKEN

GET /orgs/{org}/audit-log?phrase=repository.deleted
Authorization: Bearer YOUR_TOKEN

Interroger via GraphQL :

query {
   auditLogEntries(first: 10, query: "repository.deleted") {
     nodes {
       action
       actor { login }
       createdAt
     }
   }
 }

query {
   auditLogEntries(first: 10, query: "repository.deleted") {
     nodes {
       action
       actor { login }
       createdAt
     }
   }
 }

Filtrer et inspecter : Concentrez-vous sur les événements pertinents (repository.deleted, org.member_removed).
Remédier : Restaurez les ressources ou renforcez les paramètres de sécurité.