gitlab.md

GitLab

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:

1. Go to Site admin > Manage code hosts > Add code host
2. Select GitLab (for GitLab.com) or GitLab Self-Managed.
3. Set url to the URL of your GitLab instance, such as https://gitlab.example.com or https://gitlab.com (for GitLab.com).
4. Create a GitLab access token using these instructions with repo scope, and set it to be the value of the token.
5. Use the Repository syncing documentation below to select and add your preferred projects/repos to the configuration.
6. You can use the action buttons above the text field to add the fields, and additional fields can be added using Cmd/Ctrl+Space for auto-completion. See the configuration documentation below for additional fields.
7. Click Add repositories.

Example config:

{
  "url": "https://gitlab.com",
  "token": "<access token>",
  "projectQuery": [
    "groups/mygroup/projects",
    "projects?membership=true&archived=no",
    "?search=<search query>",
    "?membership=true\u0026search=foo"
 ],
 "projects": [
  {
     "name": "group/name"
  },
  {
      "id": 42
  }
 ]
}

Supported versions

• GitLab.com
• GitLab CE/EE (v12.0 and newer)

Repository syncing

There are three fields for configuring which projects are mirrored/synchronized:

• projects
  A list of projects in {"name": "group/name"} or {"id": id} format. The order determines the order in which we sync project metadata and is safe to change.
• 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 the projects, and projectQuery fields. It has the same format as projects.

Troubleshooting

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'

Repository permissions

By default, all Sourcegraph users can view all repositories. To configure Sourcegraph to use GitLab's per-user repository permissions, see "Repository permissions".

User authentication

To configure GitLab as an authentication provider (which will enable sign-in via GitLab), see the authentication documentation.

Internal rate limits

Internal rate limiting can be configured to limit the rate at which requests are made from Sourcegraph to GitLab.

If enabled, the default rate is set at 36,000 per hour (10 per second) which can be configured via the requestsPerHour field (see below):

• For Sourcegraph <=3.38, if rate limiting is configured more than once for the same code host instance, the most restrictive limit will be used.
• For Sourcegraph >=3.39, rate limiting should be enabled and configured for each individual code host connection.

NOTE Internal rate limiting is only currently applied when synchronising changesets in batch changes, repository permissions and repository metadata from code hosts.

Configuration

[View page on docs.sourcegraph.com](https://docs.sourcegraph.com/admin/external_service/gitlab) to see rendered content.

Native integration

To provide out-of-the-box code navigation features to your users on GitLab, you will need to configure your GitLab instance. If you are using an HTTPS connection to GitLab, you will need to configure HTTPS for your Sourcegraph 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"
  // ...
}

The site admin should also set alerts.codeHostIntegrationMessaging in global settings to ensure informational content for users in the Sourcegraph webapp references the native integration and not the browser extension.

{
  // ...
  "alerts.codeHostIntegrationMessaging": "native-integration"
  // ...
}

Access token scopes

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 or read_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, api or read_api	If you are using an external identity provider type, used to discover user accounts.
GET /users/:id	read_user, api or read_api	If using GitLab OAuth, used to fetch user metadata during the OAuth sign in process.
GET /projects/:id	api or read_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 or read_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).
Batch Changes requests	api or read_api, read_repository, write_repository	Batch Changes require write access to push commits and create, update and close merge requests on GitLab repositories. See "Code host interactions in batch changes" for details.

Webhooks

Using the webhooks property on the external service has been deprecated.

Please consult this page in order to configure webhooks.