Source control

Whose access the agent uses

When a cloud task reads your code or opens a pull request, it acts within your own access rights and never sees repositories you can't already access in the VCS provider. Connecting JetBrains Air Teams doesn't widen what you can reach – it only lets JetBrains Air Teams act on the repositories you already have access to.

• To the VCS provider, access goes through the JetBrains Air app with your authenticated user as the principal, so the provider's own permissions gate every action.

• Within JetBrains Air Teams, the cloud task operates under your user or service account.

GitHub

On GitHub, repository access goes through the JetBrains Air connection app, published as JetBrains Air in the GitHub Marketplace.

The app is installed per account, not per repository

The JetBrains Air connection app is installed into a GitHub account – a personal account or an organization – not into individual repositories. You install it once per account, then choose which repositories that installation can access: all repositories or only selected ones. You can change this selection at any time (see Manage repository access).

Installing and authorizing the app

Connecting GitHub involves two distinct actions:

• Installing the app – an administrator installs the JetBrains Air connection app into a GitHub account – a personal account or an organization – and chooses which repositories the app can access. This is what makes those repositories available to JetBrains Air Teams.

• Authorizing the app – each user authorizes the JetBrains Air connection app to act on their behalf, for example, to view issues and create pull requests. This is an OAuth flow.

Sometimes one person performs both actions. For example, when you connect your own personal account, you both install the app for that account and authorize it to act on your behalf. For an organization, an administrator usually installs the app, and each user then authorizes it for themselves.

Who can grant the app access to a repository

A user can grant app access in these cases:

• Personal repositories – if the app is installed in the user's personal account, the user can grant access to their personal repositories.

• Organization repositories – organization owners can grant the app access to organization repositories.

• Repository admins – repository administrators can grant access to repositories they administer, if the organization allows repository administrators to install GitHub apps.

Users with only normal read or write access cannot directly grant the app access to a repository. On GitHub, such repositories can appear with a Request badge instead.

If you aren't an owner or repository admin, you can't install the app yourself. When you start the connection flow, GitHub sends an installation request to your organization's owners, similar to requesting any other third-party GitHub app. After an owner approves and installs the app, you can authorize it for yourself and access the repositories you're entitled to.

But repository admins aren't notified about requests for the repositories they administer. If the repository you need is administered by a repository admin rather than an organization owner, contact them directly.

How to make a repository appear in JetBrains Air Teams

Installing the app for an organization does not mean that every repository in that organization will appear for every user in JetBrains Air Teams.

A repository appears in JetBrains Air Teams only if both of the following are true:

• the app installation has access to that repository

• the user has explicit repository access in GitHub

Repository type	When it appears in JetBrains Air Teams
Personal repository	The app is installed in the personal account and has access to the repository.
Organization public repository	The organization installation has access to the repository.
Organization private repository	The organization installation has access to the repository, and the user has explicit repository access in GitHub.
Organization internal repository	The organization installation has access to the repository, and the user has explicit repository access in GitHub. Organization membership alone is not enough. Internal repositories need special attention. A user may be able to open an internal repository directly in GitHub because they belong to the organization, but the same repository still may not appear in JetBrains Air Teams. For internal repositories, the usual fix is to grant the user explicit repository access, for example through a team or a direct collaborator role.

GitHub Enterprise Server

A self-hosted GitHub Enterprise Server instance isn't available to JetBrains Air Teams until an organization administrator registers it in JetBrains Central Console. Registration creates a GitHub App on your own server, so the instance gets its own connection app instead of using the JetBrains Air app from the GitHub Marketplace.

From there, repository access follows the same rules as GitHub: the app is installed per account, each user authorizes it for themselves, and a repository appears in JetBrains Air Teams only if both the installation and the user can reach it.

Connecting a self-hosted instance doesn't replace GitHub cloud – you can use both at the same time. If your organization registers several instances, each one appears as a separate provider in Settings | VCS Providers.

GitLab

GitLab has no installation step. You authorize JetBrains Air Teams once through OAuth, and the authorization is scoped to you: cloud tasks can use any repository you can access in GitLab.

The authorization requests these GitLab scopes:

• api – acting on your behalf through the GitLab API, for example, to open a merge request

• read_repository – cloning the repository into the cloud environment

• write_repository – pushing the task branch back to GitLab

To change which repositories a cloud task can reach, change your own access in GitLab.

GitLab Self-Managed

A self-hosted GitLab Self-Managed instance isn't available to JetBrains Air Teams until an organization administrator registers it in JetBrains Central Console. Registration connects an OAuth application from your own server, so JetBrains Air Teams authenticates against that server instead of GitLab.com.

From there, access works exactly like GitLab: nothing is installed, you authorize JetBrains Air Teams for yourself, and cloud tasks can use any repository you can access on that server. The organizations shown for the connection are your GitLab namespaces.

Connecting a self-hosted instance doesn't replace GitLab.com – you can use both at the same time. If your organization registers several instances, each one appears as a separate provider in Settings | VCS Providers.