Remarque : seules les organisations qui utilisent GitHub Enterprise Cloud peuvent créer des rôles de référentiel personnalisés.Pour plus d’informations sur la façon d’essayer gratuitement GitHub Enterprise Cloud, consultez « Configuration d’un essai de GitHub Enterprise Cloud ».
À propos des rôles de référentiel personnalisés
Pour effectuer toute action sur GitHub Enterprise Cloud, comme la création d’une demande de tirage dans un référentiel ou la modification des paramètres de facturation d’une organisation, une personne doit disposer d’un accès suffisant au compte ou à la ressource approprié. Cet accès est contrôlé par les autorisations. Une autorisation est la possibilité d’effectuer une action spécifique. Par exemple, la possibilité de supprimer un problème est une autorisation. Un rôle est un ensemble d’autorisations que vous pouvez attribuer à des personnes ou des équipes.
Au sein d’une organisation, vous pouvez attribuer des rôles au niveau de l’organisation, de l’équipe et du référentiel. Pour plus d’informations sur les différents niveaux de rôle, consultez « Rôles dans une organisation ».
Vous pouvez avoir un contrôle plus granulaire sur les autorisations que vous accordez au niveau du dépôt en créant jusqu’à cinq rôles de dépôt personnalisés. Un rôle de référentiel personnalisé est un ensemble configurable d’autorisations avec un nom personnalisé que vous choisissez. Pour plus d’informations, consultez « Gestion des rôles de référentiel personnalisés pour une organisation ».
Une fois que vous avez créé un rôle personnalisé, toute personne disposant d’un accès administrateur à un référentiel peut affecter le rôle à une personne ou à une équipe. Pour plus d’informations, consultez « Gestion de l’accès d’une personne à un dépôt d’organisation » et « Gestion de l’accès de l’équipe à un dépôt de l’organisation ».
Vous pouvez également utiliser l’API REST pour créer et gérer des rôles de dépôt personnalisés. Pour plus d’informations, consultez « Points de terminaison d’API REST pour les rôles de référentiel personnalisés ».
Les rôles de dépôt personnalisés gèrent l’accès aux dépôts spécifiques de votre organisation. Pour accorder l’accès à tous les dépôts et contrôler l’accès aux paramètres d’administration de votre organisation, vous pouvez utiliser des rôles d’organisation personnalisés. Consultez « À propos des rôles d'organisation personnalisés ».
Les rôles d’organisation personnalisés diffèrent des rôles de dépôt, car ils accordent des autorisations pour tous les dépôts actuels et futurs de l’organisation. Toutefois, les rôles de dépôt personnalisés vous permettent d’accorder des autorisations à des dépôts spécifiques au sein de l’organisation.
À propos du rôle hérité
Lorsque vous créez un rôle de référentiel personnalisé, vous commencez par choisir un rôle hérité à partir d’un ensemble d’options prédéfinies. Le rôle hérité détermine l’ensemble initial d’autorisations inclus dans le rôle personnalisé. Ensuite, vous pouvez personnaliser davantage le rôle en choisissant des autorisations supplémentaires à donner au rôle. Pour obtenir la liste complète des autorisations disponibles, consultez « Autorisations supplémentaires pour les rôles personnalisés ».
Vos options pour le rôle hérité sont normalisées pour différents types de contributeurs dans votre référentiel.
| Rôle hérité | Conçu pour |
|---|---|
| Lire | Contributeurs hors code qui veulent voir votre projet ou en discuter |
| Tri | Contributeurs qui doivent gérer de façon proactive les problèmes et les demandes de tirage (pull requests) sans accès en écriture |
| Écrire | Membres et collaborateurs de l’organisation qui contribuent activement à votre projet |
| Maintenance | Chefs de projet qui doivent gérer le dépôt sans avoir accès à des actions sensibles ou destructrices |
Exemples de rôles personnalisés
Voici quelques exemples de rôles de référentiel personnalisés que vous pouvez configurer.
| Rôle de référentiel personnalisé | Résumé | Rôle hérité | Autorisations supplémentaires |
|---|---|---|---|
| Security Engineer | Capable de contribuer au code et de gérer le pipeline de sécurité | Maintenance | Supprimer les résultats de l’analyse du code |
| Contractor | Capable de développer des intégrations de webhooks | Écrire | Gérer les webhooks |
| Gestionnaire de la communauté | Capable de gérer toutes les interactions de la communauté sans pouvoir contribuer au code | Lire | - Marquer un problème comme dupliqué - Gérer les paramètres de la page GitHub - Gérer les paramètres du wiki - Définir l’aperçu social - Modifier les métadonnées du référentiel - Discussions de triage |
Autorisations supplémentaires pour les rôles personnalisés
Après avoir choisi un rôle hérité, vous pouvez sélectionner des autorisations supplémentaires pour votre rôle personnalisé.
Vous ne pouvez choisir qu’une autorisation supplémentaire si elle n’est pas déjà incluse dans le rôle hérité. Par exemple, si le rôle hérité offre un accès en écriture à un référentiel, l’autorisation « Fermer une demande de tirage » sera déjà incluse dans le rôle hérité.
Discussions
- Créer une catégorie de discussion
- Modifier une catégorie de discussion
- Supprimer une catégorie de discussion
- Marquer ou supprimer le marquage des réponses de discussion
- Masquer ou afficher les commentaires de discussion
- Convertir des problèmes en discussions
Pour plus d’informations, consultez « Documentation GitHub Discussions ».
Problème et demandes d’extraction
- Affecter ou supprimer un utilisateur
- Ajouter ou supprimer une étiquette
Problème
- Fermer un problème
- Rouvrir un problème fermé
- Supprimer un problème
- Marquer un problème en tant que doublon
Demande de tirage (pull request)
- Fermer une demande de tirage
- Rouvrir une demande de tirage fermée
- Demander une révision de demande de tirage
Dépôt
- Définir des jalons
- Gérer les paramètres du wiki
- Gérer les paramètres du projet
- Gérer les paramètres de fusion des demandes de tirage
- Gérer les paramètres GitHub Pages (voir « Configuration d’une source de publication pour votre site GitHub Pages »)
- Gérer les webhooks
- Gérer les clés de déploiement
- Modifier les métadonnées de dépôt
- Définir les limites d’interaction
- Définir l’aperçu social
- Envoyer (push) des commits vers des branches protégées
- Le rôle de base doit être
write - Les règles de protection des branches s’appliquent toujours
- Le rôle de base doit être
- Créer des étiquettes protégées
- Supprimer les balises protégées
- Contourner les protections de branches
- Modifier les règles de dépôt
Sécurité
- Afficher les résultats d’code scanning
- Ignorer ou rouvrir les résultats d’code scanning
- Supprimer les résultats d’code scanning
- Afficher les Dependabot alerts
- Ignorer ou rouvrir les Dependabot alerts
- Afficher les résultats d’secret scanning
- Ignorer ou rouvrir les résultats d’secret scanning
Priorité pour différents niveaux d’accès
Les rôles et autorisations sont additifs. Si une personne reçoit différents niveaux d’accès par le biais de différentes voies, telles que l’appartenance à une équipe et les autorisations de base d’une organisation, l’utilisateur dispose de la somme de toutes les autorisations d’accès. Par exemple, si un propriétaire d’organisation donne à un membre de l’organisation un rôle personnalisé qui utilise le rôle hérité « Lecture », puis qu’un propriétaire de l’organisation définit l’autorisation de base de l’organisation sur « Écriture », les membres ayant le rôle personnalisé auront un accès en écriture, ainsi que toutes les autorisations supplémentaires incluses dans le rôle personnalisé.
Si une personne a reçu un accès en conflit, un avertissement s’affiche sur la page d’accès au dépôt. L’avertissement s’affiche avec « Rôles mixtes » en regard de la personne disposant de l’accès en conflit. Pour voir la source de l’accès en conflit, positionnez le curseur sur l’icône d’avertissement ou cliquez sur Rôles mixtes.
Pour résoudre les conflits d’accès, vous pouvez ajuster les autorisations de base de votre organisation ou l’accès de l’équipe, ou modifier le rôle personnalisé. Pour plus d'informations, consultez les pages suivantes :