Repositories
Integrations → Repositories connects your Git provider (GitHub or GitLab) to the workspace, then lets you import specific repositories into a project. It is the one integration Knowledge's Discovery step actually requires. Everything else on the platform that reads or changes code (Discovery, agents on the Development board, Pull Requests, Deployments) is grounded on a repository connected here.
The page is really two layers stacked on top of each other.
- Provider accounts: connect a GitHub or GitLab account to the workspace (OAuth, or a personal access token). This is workspace-scoped: once connected, the account is available to every project, but each project can use only one account per provider at a time.
- Repositories: pick a connected account and import one or more of its repos into a specific project. This is what actually shows up as a "repository" everywhere else in the app.
In this section
- Connecting and managing a provider account: OAuth vs. personal access token, reconnecting on token expiry, disconnecting, and assigning which project uses which account.
- Importing and managing repositories: the 5-step Connect Repository wizard (with validation), the repository list, moving a repo between projects, disconnecting, and repairing provider event (webhook) delivery.
The workflow, in order
- Connect a provider account. Click connect on the GitHub or GitLab card to run OAuth, or use a token to paste a personal access token. See Connecting a provider account.
- Assign that account to a project (if it is not already the project's only option), either from the account's gear icon → Manage accounts, or implicitly when you pick it in the import wizard.
- Import a repository into a project with Connect Repository: pick the project, the account, the repo (from a searchable list or a pasted link), and a branch. ACE validates read, write, webhook, and CI access against the provider before letting you confirm.
- The repository now powers the rest of the platform: Knowledge needs at least one connected repository before it can map your code; Pull Requests lists PRs pulled live from it; Deployments lists CI/CD runs reported against it.
- If sync breaks (token expired, access revoked), the repository shows an Error badge and a banner offers to reconnect the provider account. Reconnecting once revives every repository that shares that account.
Where to find it
Left sidebar → Integrations → Repositories, or go straight to /integrations/repositories (the older /repositories link still redirects here). It is a per-project view for the repository list (pick the project with the sidebar's project switcher), but provider accounts themselves are workspace-scoped and shared across every project. A workspace admin can also reach it as a link-out card from Connections.
Permissions
| Grant | Scope | Controls |
|---|---|---|
repo:read | project | Required just to open the Repositories page and see the repository list. |
repo:manage | project | Connect Repository, importing and validating a repo, moving a repo to another project, disconnecting a repo, and Repair provider events. Disabled entirely on an archived or otherwise non-mutable project. |
org:integrations:manage | workspace | Connecting, disconnecting, or reconnecting a GitHub or GitLab account; opening the account's Manage accounts modal to change which projects it serves. Without it, the page shows "This workspace grants integration visibility only" and every connect and disconnect control is hidden. |
org:integrations:read | workspace | Implicit baseline for seeing provider connection state on this and the other Integrations pages. |
Reconnecting a specific repository's provider (the banner shown after a sync failure) needs both repo:manage and org:integrations:manage, and the workspace must still be mutable; a repo-level grant alone is not enough to touch the shared account.