Site admins can sync Git repositories hosted on GitLab (GitLab.com and GitLab CE/EE) with Sourcegraph so that users can search and navigate the repositories.
To connect GitLab to Sourcegraph:
- Go to Site admin > Manage repositories > Add repositories
- Select GitLab.
- Configure the connection to GitLab using the action buttons above the text field, and additional fields can be added using Cmd/Ctrl+Space for auto-completion. See the configuration documentation below.
- Press Add repositories.
- GitLab.com
- GitLab CE/EE (v10.0 and newer)
There are three fields for configuring which projects are mirrored/synchronized:
projects
A list of projects in{"name": "group/name"}or{"id": id}format.projectQuery
A list of strings with one pre-defined option (none), and/or an URL path and query that targets a GitLab API endpoint returning a list of projects.exclude
A list of projects to exclude which takes precedence over theprojects, andprojectQueryfields. It has the same format asprojects.
You can test your access token's permissions by running a cURL command against the GitLab API. This is the same API and the same project list used by Sourcegraph.
Replace $ACCESS_TOKEN with the access token you are providing to Sourcegraph, and $GITLAB_HOSTNAME with your GitLab hostname:
curl -H 'Private-Token: $ACCESS_TOKEN' -XGET 'https://$GITLAB_HOSTNAME/api/v4/projects'
By default, all Sourcegraph users can view all repositories. To configure Sourcegraph to use GitLab's per-user repository permissions, see "Repository permissions".
To configure GitLab as an authentication provider (which will enable sign-in via GitLab), see the authentication documentation.
To provide out-of-the-box code intelligence and navigation features to your users on GitLab, you will need to configure your GitLab instance.
The Sourcegraph instance's site admin must update the corsOrigin site config property to allow the GitLab instance to communicate with the Sourcegraph instance. For example:
{
// ...
"corsOrigin":
"https://my-gitlab.example.com"
// ...
}Sourcegraph requires an access token with api permissions (and sudo, if you are using an external identity provider type). These permissions are required for the following reasons:
We are actively collaborating with GitLab to improve our integration (e.g. the Sourcegraph GitLab native integration and better APIs for querying repository permissions).
| Request Type | Required GitLab scope | Sourcegraph usage |
|---|---|---|
GET /projects |
api |
(1) For repository discovery when specifying projectQuery in code host configuration; (2) If using an external identity provider type, also used as a test query to ensure token is sudo (sudo not required otherwise). |
GET /users |
read_user or api |
If you are using an external identity provider type, used to discover user accounts. |
GET /users/:id |
read_user or api |
If using GitLab OAuth, used to fetch user metadata during the OAuth sign in process. |
GET /projects/:id |
api |
(1) If using GitLab OAuth and repository permissions, used to determine if a user has access to a given project; (2) Used to query repository metadata (e.g. description) for display on Sourcegraph. |
GET /projects/:id/repository/tree |
api |
If using GitLab OAuth and repository permissions, used to verify a given user has access to the file contents of a repository within a project (i.e. does not merely have Guest permissions). |
| (future) write access | api |
graph site-admins (only) to perform large-scale code refactors, with Sourcegraph issuing and managing the merge requests on GitLab repositories, company-wide. |