Contrôler l’utilisation des référentiels dans votre organisation

Pour contrôler les événements clés du cycle de vie de vos référentiels, tels que les personnes autorisées à créer ou à supprimer des référentiels, vous pouvez créer une stratégie de référentiel. Une stratégie de référentiel est un ensemble de restrictions qui vous permet de contrôler de manière flexible quels utilisateurs sont concernés et quels référentiels sont ciblés.

Dans une stratégie de référentiel, vous pouvez restreindre :

• Quelles visibilités sont autorisées pour les nouveaux référentiels et les modifications de visibilité.
• Qui peut créer des référentiels.
• Qui peut supprimer des référentiels.
• Qui peut transférer des référentiels hors d’une organisation.
• Comment les personnes peuvent nommer les référentiels.

Exemples

Vous pouvez utiliser une stratégie de référentiel pour effectuer des opérations telles que :

• S’assurer que tous les nouveaux référentiels utilisent une certaine convention de nommage, telle que kebab-case.
• Empêcher les suppressions de référentiels, sauf par les administrateurs de l’organisation.
• Autoriser la création de référentiels publics uniquement dans l’organisation « open source » de votre entreprise.
• Empêcher que les référentiels publics ne soient transformés en référentiels privés afin d’éviter la perte potentielle de métadonnées.

Comment vais-je cibler les référentiels ?

Nous vous recommandons d’utiliser les stratégies de référentiel parallèlement aux propriétés de référentiel personnalisées. En ajoutant des propriétés personnalisées aux référentiels, vous pourrez cibler ces référentiels de manière flexible dans une stratégie.

Par exemple, vous pouvez ajouter une propriété pour marquer les référentiels qui contiennent des données de production ou d'autres informations sensibles, puis empêcher quiconque de rendre ces référentiels publics.

Pour créer et définir des propriétés personnalisées, consultez Gestion des propriétés personnalisées pour les référentiels de votre organisation.

Au lieu d’utiliser des propriétés personnalisées, vous pouvez choisir parmi une liste de référentiels ou utiliser la syntaxe fnmatch pour cibler les référentiels avec certains modèles de nommage.

Interaction avec d’autres stratégies

Certaines des restrictions disponibles sont des doublons des stratégies que vous avez peut-être définies sur la page « Privilèges des membres » dans les paramètres de votre organisation ou de votre entreprise.

La création d’une stratégie de référentiel ne remplace pas vos stratégies de « privilèges des membres » existantes. Les stratégies sont plutôt additives, de sorte que la version la plus restrictive d’une stratégie s’applique. Cela s’applique à la fois aux ** stratégies de privilèges des membres** et aux autres ** stratégies de référentiel** créées au niveau de l’entreprise ou de l’organisation.

Par rapport aux stratégies de privilèges des membres, les stratégies de référentiel présentent plusieurs avantages :

• Elles offrent un ciblage plus flexible des organisations et des référentiels.
• Elles vous permettent de donner à certains acteurs la possibilité de contourner les stratégies.

Création d’une stratégie de référentiel

1. Dans le coin supérieur droit de GitHub, cliquez sur votre photo de profil, puis sur Vos organisations.

2. Sélectionnez une organisation en cliquant dessus.

3. Sous le nom de votre organisation, cliquez sur Settings. Si vous ne voyez pas l’onglet « Paramètres », sélectionnez le menu déroulant , puis cliquez sur Paramètres.

   

4. Sur le côté gauche de la page, dans la barre latérale, cliquez sur Stratégies.

5. Dans « Stratégies », cliquez sur Référentiel.

6. Cliquez sur Nouvelle stratégie.

7. Configurez votre nouvelle stratégie, puis cliquez sur Créer. Pour obtenir de l’aide, consultez les sous-sections suivantes.

Nom de stratégie

Utilisez une formule descriptive pour communiquer l’objectif de la stratégie. Par exemple : Prevent public repos on production.

État d’application

Si vous ne souhaitez pas que la stratégie soit appliquée lors de sa création, sélectionnez « Désactivée ». Dans le cas contraire, sélectionnez « Active ».

Liste d’autorisation

Choisissez les rôles qui peuvent contourner les restrictions de cette stratégie.

Cibles

Choisissez les référentiels de l’organisation auxquels la stratégie s’applique. Vous pouvez sélectionner tous les référentiels, choisir une sélection de référentiels existants ou créer une règle dynamique par nom ou par propriété personnalisée pour les référentiels actuels et futurs.

Si vous définissez une liste dynamique par son nom, vous ajouterez un ou plusieurs modèles de nommage en utilisant la syntaxe fnmatch.

• Par exemple, la chaîne *open-source correspond à tout référentiel dont le nom se termine par open-source. Pour plus d’informations sur la syntaxe, consultez Création d'ensembles de règles pour un dépôt.
• Vous avez également la possibilité d’empêcher toute personne ne figurant pas dans la liste des personnes autorisées de renommer les référentiels sélectionnés. Vous pouvez également contrôler le format des noms dans la section « Stratégies ».

Stratégies

Choisissez les restrictions à inclure. Lorsque la stratégie est active, les restrictions s’appliquent à tous les référentiels ciblés, mais peuvent être contournées par les utilisateurs ou les équipes figurant sur la liste d’autorisation.

Si vous choisissez la stratégie « Restreindre les noms », vous devez utiliser la syntaxe expression régulière pour définir un modèle auquel les noms de référentiels doivent ou ne doivent pas correspondre. Par exemple, un modèle permettant d’appliquer le nommage kebab-case ressemblerait à ^([a-z][a-z0-9]*)(-[a-z0-9]+)*$.

• Les modèles prennent en charge la syntaxe RE2. Consultez le guide de syntaxe de Google.
• Pour valider vos expressions, cliquez sur Tester le modèle, puis entrez un modèle et une valeur de test.

Déléguer le contournement des stratégies

Le contournement délégué des stratégies de dépôt vous permet de contrôler qui peut contourner les stratégies de dépôt pour les suppressions et les modifications de visibilité du dépôt.

Avec le contournement délégué, les administrateurs du dépôt doivent soumettre une demande pour modifier la visibilité du dépôt ou le supprimer. La demande est envoyée à un groupe désigné de réviseurs, qui approuvent ou rejettent la demande visant à contourner les stratégies du dépôt.

Si la demande de contournement des stratégies du dépôt est approuvée, la modification demandée est immédiatement effectuée. Si la demande est rejetée, la modification demandée n’est pas effectuée, mais peut faire l’objet d’une nouvelle demande.

Pour configurer le contournement délégué, les propriétaires d’entreprise ou d’organisation doivent d’abord créer une « liste de contournement ». La liste de contournement comprend des rôles et des équipes spécifiques, tels que les administrateurs d’équipe ou de dépôt, qui supervisent les demandes de contournement des stratégies de dépôt.

Gestion des demandes de contournement

Gérer les demandes de contournement des règles de poussée

Vous pouvez consulter et gérer toutes les demandes de privilèges de contournement sur la page « Demandes de contournement », située sous les paramètres Stratégie.

Vous pouvez filtrer les demandes par approbateur (membre de la liste de contournement), demandeur (contributeur en effectuant la demande), délai et état. Les états suivants sont attribués à une demande :

Statut	Description
Cancelled	La demande a été annulée par le contributeur.
Completed	La demande a été approuvée et les commits ont été envoyées au référentiel.
Denied	La demande a été examinée et refusée.
Expired	La demande a expiré. Les demandes sont valides pendant 7 jours.
Open	La demande n’a pas encore été examinée, ou a été approuvée, mais le(s) commits n’a(ont) pas été envoyés dans le référentiel.

Lorsqu'un contributeur demande des privilèges de contournement pour publier un commit contenant un contenu restreint, les membres de la liste de contournement reçoivent tous une notification par courrier électronique contenant un lien vers la demande. Les membres de la liste de contournement disposent alors de sept jours pour examiner la demande et l’approuver ou la refuser avant qu’elle n’expire.

Le contributeur est notifié de la décision par e-mail et doit prendre les mesures requises. Si la demande est approuvée, le contributeur peut envoyer (push) le commit contenant le contenu restreint dans le référentiel. Si la demande est refusée, le contributeur doit supprimer le contenu restreint du commit pour que ce dernier puisse être envoyé dans le référentiel.