Git repositories

Connecting GitHub or GitLab, deciding who in the organization may build from your repositories, and what happens when you leave.

Applications are built from repositories reached through a GitHub or GitLab account that someone in your organization connected. Every clone the platform makes goes through that account's credential. So the person who connected an account decides who else may build from its repositories, not the organization's administrators.

Connecting an account

Each member connects their own account, from the Integrations page of the console. Developers can do this; it needs no administrator.

GitHub. You install the ISOGrid GitHub app on your account or on a GitHub organization you manage, and choose which repositories it may read. Only those repositories become visible to the platform. You can widen the selection later in GitHub.

GitLab. You sign in to GitLab and approve access, or paste a group, project or personal access token. Self-hosted GitLab instances work the same way, including projects in nested groups.

Once connected, your repositories appear in the console and in isogrid repos list, with you as their owner.

Connect only what you intend to deploy. Selecting a handful of repositories in GitHub costs nothing and means a mistake here exposes nothing else.

Who can reach a repository

Every repository has a visibility.

Invitations add to any of the three: a private repository can still be granted to one contractor or one group.

Under Administrators and Organization, the owner and administrators hold everything on the repository except deciding who else gets in. That stays with you.

Under Organization, every member holds what you chose. Unless you choose otherwise, that is: view it, create applications from it, build and deploy them, and change their configuration. Not deleting applications other people built from it, and not sharing it further.

A private repository is not merely hidden from lists. It does not answer to its name, so nobody can find out it exists by guessing.

Defaults, and settings per repository

Visibility is set in two places:

• On the connection, as the default for every repository it brings in. New connections start private. Change the default in the connection's settings on the Integrations page.
• On one repository, overriding the default. Set it back to inherit to follow the connection again.

isogrid repos access acme/api --visibility organization
isogrid repos access acme/api --visibility inherit

isogrid repos list marks a repository that follows its connection with (default).

Connections made before these settings existed are organization-wide. They were usable by every member before, and they stay so until their owner changes them. If you connected an account a while ago, review it.

Inviting members and groups

Grant a repository to one member or to a permission group, with a preset:

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

No preset includes repo:share: whoever you invite cannot invite others. As with every grant, you can give only what you hold; see Roles, permission groups and access.

What a repository capability allows on its applications

A capability on a repository reaches every application built from it, including ones created after the grant. Nobody has to be added to each application separately.

These add to whatever the person holds on the application itself.

Deploying is gated by the repository

Building or deploying an application needs repo:deploy on its repository, whatever the person holds on the application. A build clones with the connector's credential, so the connector's policy has the last word.

This is what makes taking a repository private mean something. Close it, and the applications built from it stop being deployable by anyone you have not invited — including administrators, including members who created those applications while it was open. The applications keep running; they just cannot be rebuilt or redeployed by people the repository is closed to.

When the connector leaves

When the member who connected an account leaves the organization or is suspended in it, nobody is left to decide for its repositories. Whoever may manage the organization's git connections (owners and administrators) takes over: they hold everything on those repositories, can change their visibility, invite and remove people, or disconnect the account.

Everything the connector set stays in force until someone changes it. An organization-wide repository stays organization-wide; a private one stays closed to everyone but those invited, and administrators can open it.

The account itself is still the connector's. If they revoke the app in GitHub or the token in GitLab, builds stop, whatever the settings here say. Plan to reconnect those repositories through someone who is staying.

Disconnecting

The connector can disconnect their own account; an administrator can disconnect anyone's. Applications built from its repositories keep running, but cannot be built again until the repositories are reachable through another connection.

Edge cases worth knowing before you meet them

"is not a repository you have been given access to". It is private, or open to administrators and you are not one. Ask the owner, shown in isogrid repos list to those who can see it, to invite you.

"You do not have 'repo:deploy' on acme/api". You can see the repository but not build from it. You may hold app:deploy on the application; the repository still has to allow it.

A deployment worked yesterday and is refused today. The repository was made private, or your grant was revoked. The application is untouched; ask the owner.

An administrator cannot change a repository's visibility. While its connector is a member, only they can. Administrators take over once the connector has left.

A repository does not appear at all. It was not selected when the GitHub app was installed, or the GitLab token cannot read it. Widen the selection in GitHub or GitLab; nothing needs to change here.

The CLI is refused where the console works, on a repository open to administrators. Administrator access to repositories rests on the github:manage permission. Approve a credential that includes it.

What to read next

• Roles, permission groups and access
• Repositories, groups and access
• Deploying an application