Dépôts Git
Connecter GitHub ou GitLab, décider qui dans l'organisation peut construire à partir de vos dépôts, et ce qui se passe quand vous partez.
Les applications sont construites à partir de dépôts accessibles par un compte GitHub ou GitLab qu'une personne de votre organisation a connecté. Chaque clone effectué par la plateforme passe par l'identifiant de ce compte. C'est donc la personne qui a connecté un compte qui décide qui d'autre peut construire à partir de ses dépôts, et non les administrateurs de l'organisation.
Connecter un compte
Chaque membre connecte son propre compte, depuis la page Integrations (intégrations) de la console. Les développeurs peuvent le faire ; aucun administrateur n'est nécessaire.
GitHub. Vous installez l'application GitHub d'ISOGrid sur votre compte ou sur une organisation GitHub que vous gérez, et vous choisissez les dépôts qu'elle peut lire. Seuls ces dépôts deviennent visibles pour la plateforme. Vous pourrez élargir la sélection plus tard dans GitHub.
GitLab. Vous vous connectez à GitLab et approuvez l'accès, ou vous collez un jeton d'accès de groupe, de projet ou personnel. Les instances GitLab auto-hébergées fonctionnent de la même façon, y compris les projets dans des groupes imbriqués.
Une fois le compte connecté, vos dépôts apparaissent dans la console et dans
isogrid repos list, avec vous comme propriétaire.
Ne connectez que ce que vous comptez déployer. Sélectionner une poignée de dépôts dans GitHub ne coûte rien, et garantit qu'une erreur ici n'expose rien d'autre.
Qui peut accéder à un dépôt
Chaque dépôt a une visibilité.
| Visibilité | Qui peut l'utiliser |
|---|---|
| Privé | Vous, et les personnes que vous invitez. Personne d'autre, pas même le propriétaire de l'organisation. |
| Administrateurs | En plus, le propriétaire de l'organisation et ses administrateurs. |
| Organisation | En plus, chaque membre, avec les capacités que vous avez choisies. |
Les invitations s'ajoutent à chacune des trois : un dépôt privé peut quand même être accordé à un prestataire ou à un groupe.
En mode Administrateurs et Organisation, le propriétaire et les administrateurs détiennent tout sur le dépôt, sauf le choix de qui d'autre peut entrer. Ce choix vous reste.
En mode Organisation, chaque membre détient ce que vous avez choisi. Sauf choix contraire de votre part, cela signifie : voir le dépôt, créer des applications à partir de lui, les construire et les déployer, et modifier leur configuration. Pas supprimer les applications que d'autres en ont tirées, ni partager le dépôt plus loin.
Un dépôt privé n'est pas seulement absent des listes. Il ne répond pas à son nom : personne ne peut donc découvrir son existence en devinant.
Valeurs par défaut et réglages par dépôt
La visibilité se règle à deux endroits :
- Sur la connexion, comme valeur par défaut pour tous les dépôts qu'elle apporte. Les nouvelles connexions démarrent en privé. Modifiez la valeur par défaut dans les paramètres de la connexion, sur la page Integrations.
- Sur un dépôt, en remplaçant la valeur par défaut. Remettez-la sur inherit (hériter) pour suivre de nouveau la connexion.
isogrid repos access acme/api --visibility organization
isogrid repos access acme/api --visibility inherit
isogrid repos list signale par (default) un dépôt qui suit sa connexion.
Les connexions créées avant l'existence de ces réglages sont ouvertes à toute l'organisation. Elles étaient utilisables par tous les membres auparavant, et le restent jusqu'à ce que leur propriétaire les modifie. Si vous avez connecté un compte il y a quelque temps, vérifiez-le.
Inviter des membres et des groupes
Accordez un dépôt à un membre ou à un groupe de permissions, avec un préréglage :
| Préréglage | Capacités | Ils peuvent |
|---|---|---|
repo-viewer |
repo:view |
Voir le dépôt, ses branches et ses commits. |
repo-deployer |
en plus repo:create-app, repo:deploy |
Créer des applications à partir de lui, les construire et les déployer. |
repo-maintainer |
en plus repo:update |
Modifier aussi la configuration et les secrets de ces applications. |
repo-admin |
en plus repo:delete |
Supprimer aussi ces applications. |
isogrid repos grant acme/api --member contractor@partner.example --preset repo-deployer
isogrid repos grant acme/api --group backend --preset repo-maintainer
isogrid repos grants acme/api
isogrid repos revoke acme/api contractor@partner.example
Aucun préréglage n'inclut repo:share : les personnes que vous invitez ne
peuvent pas en inviter d'autres. Comme pour tout accès, vous ne pouvez donner que
ce que vous détenez ; voir
Rôles, groupes de permissions et accès.
Ce qu'une capacité sur un dépôt permet sur ses applications
Une capacité sur un dépôt s'étend à toutes les applications construites à partir de lui, y compris celles créées après l'octroi. Personne n'a besoin d'être ajouté séparément à chaque application.
| Sur le dépôt | Sur chaque application construite à partir de lui |
|---|---|
repo:view |
Rien encore : voir le dépôt, ses branches et ses commits. |
repo:create-app |
Créer de nouvelles applications à partir de lui. |
repo:deploy |
La voir, lire ses journaux, la construire et la déployer, la démarrer et l'arrêter. |
repo:update |
La voir, lire ses journaux, modifier sa configuration et ses secrets. |
repo:delete |
La voir et la supprimer. |
repo:share |
Décider qui d'autre peut utiliser le dépôt. |
Ces capacités s'ajoutent à ce que la personne détient sur l'application elle-même.
Le déploiement est conditionné par le dépôt
Construire ou déployer une application exige repo:deploy sur son dépôt,
quoi que la personne détienne sur l'application. Une construction clone avec
l'identifiant de la personne qui a connecté le compte : c'est donc sa politique
qui a le dernier mot.
C'est ce qui donne un sens au passage d'un dépôt en privé. Fermez-le, et les applications construites à partir de lui ne peuvent plus être déployées par quiconque vous n'avez pas invité — administrateurs compris, membres compris qui ont créé ces applications quand le dépôt était ouvert. Les applications continuent de tourner ; elles ne peuvent simplement plus être reconstruites ou redéployées par les personnes à qui le dépôt est fermé.
Quand la personne qui a connecté le compte part
Quand le membre qui a connecté un compte quitte l'organisation ou y est suspendu, plus personne ne peut décider pour ses dépôts. Ceux qui peuvent gérer les connexions git de l'organisation (propriétaires et administrateurs) prennent le relais : ils détiennent tout sur ces dépôts, peuvent modifier leur visibilité, inviter et retirer des personnes, ou déconnecter le compte.
Tout ce que cette personne avait réglé reste en vigueur jusqu'à ce que quelqu'un le modifie. Un dépôt ouvert à toute l'organisation le reste ; un dépôt privé reste fermé à tous sauf aux personnes invitées, et les administrateurs peuvent l'ouvrir.
Le compte lui-même appartient toujours à la personne qui l'a connecté. Si elle révoque l'application dans GitHub ou le jeton dans GitLab, les constructions s'arrêtent, quels que soient les réglages définis ici. Prévoyez de reconnecter ces dépôts via quelqu'un qui reste.
Déconnecter
La personne qui a connecté un compte peut le déconnecter ; un administrateur peut déconnecter celui de n'importe qui. Les applications construites à partir de ses dépôts continuent de tourner, mais ne peuvent plus être reconstruites tant que les dépôts ne sont pas accessibles par une autre connexion.
Cas particuliers à connaître avant d'y être confronté
« is not a repository you have been given access to ». Le dépôt est privé,
ou ouvert aux administrateurs et vous n'en êtes pas un. Demandez au
propriétaire, affiché dans isogrid repos list pour ceux qui peuvent voir le
dépôt, de vous inviter.
« You do not have 'repo:deploy' on acme/api ». Vous pouvez voir le dépôt
mais pas construire à partir de lui. Vous détenez peut-être app:deploy sur
l'application ; le dépôt doit tout de même l'autoriser.
Un déploiement qui fonctionnait hier est refusé aujourd'hui. Le dépôt est passé en privé, ou votre accès a été retiré. L'application n'est pas touchée ; adressez-vous au propriétaire.
Un administrateur ne peut pas modifier la visibilité d'un dépôt. Tant que la personne qui l'a connecté est membre, elle seule le peut. Les administrateurs prennent le relais une fois qu'elle est partie.
Un dépôt n'apparaît pas du tout. Il n'a pas été sélectionné lors de l'installation de l'application GitHub, ou le jeton GitLab ne peut pas le lire. Élargissez la sélection dans GitHub ou GitLab ; rien n'est à modifier ici.
La CLI est refusée là où la console fonctionne, sur un dépôt ouvert aux
administrateurs. L'accès des administrateurs aux dépôts repose sur la
permission github:manage. Approuvez un identifiant qui l'inclut.