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 the read_api and read_repository scopes, 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 the GitLab Projects 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

GitLab permissions can be configured in three ways:

  1. Set up GitLab as an OAuth sign-on provider for Sourcegraph (recommended)
  2. Use a GitLab administrator (sudo-level) personal access token in conjunction with another SSO provider (recommended only if the first option is not possible)
  3. Assume username equivalency between Sourcegraph and GitLab (warning: this is generally unsafe and should only be used if you are using strictly http-header authentication).

OAuth application

Prerequisite: Add GitLab as an authentication provider.

Then, add or edit a GitLab connection and include the authorization field:

{
  "url": "https://gitlab.com",
  "token": "$PERSONAL_ACCESS_TOKEN",
  // ...
  "authorization": {
    "identityProvider": {
      "type": "oauth"
    }
  }
}

In this case, a user's OAuth token will be used to get a list of repositories that the user can access. Repository-centric permissions syncing will be disabled.

Administrator (sudo-level) access token

This method requires administrator access to GitLab so that Sourcegraph can access the admin GitLab Users API endpoint. For each GitLab user, this endpoint provides the user ID that comes from the authentication provider, so Sourcegraph can associate a user in its system to a user in GitLab.

Prerequisite: Add the SAML or OpenID Connect authentication provider you use to sign into GitLab.

Then, add or edit a GitLab connection using an administrator (sudo-level) personal access token, and include the authorization field:

{
  "url": "https://gitlab.com",
  "token": "$PERSONAL_ACCESS_TOKEN",
  // ...
  "authorization": {
    "identityProvider": {
      "type": "external",
      "authProviderID": "$AUTH_PROVIDER_ID",
      "authProviderType": "$AUTH_PROVIDER_TYPE",
      "gitlabProvider": "$AUTH_PROVIDER_GITLAB_ID"
    }
  }
}

$AUTH_PROVIDER_ID and $AUTH_PROVIDER_TYPE identify the authentication provider to use and should match the fields specified in the authentication provider config (auth.providers). The authProviderID can be found in the configID field of the auth provider config.

$AUTH_PROVIDER_GITLAB_ID should match the identities.provider returned by the admin GitLab Users API endpoint.

Username

Prerequisite: Ensure that http-header is the only authentication provider type configured for Sourcegraph. If this is not the case, then it will be possible for users to escalate privileges, because Sourcegraph usernames are mutable.

Add or edit a GitLab connection and include the authorization field:

{
  "url": "https://gitlab.com",
  "token": "$PERSONAL_ACCESS_TOKEN",
  // ...
  "authorization": {
    "identityProvider": {
      "type": "username"
    }
  }
}

User authentication

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

Internal repositories

GitLab also has internal repositories in addition to the usual public and private repositories. Depending on how your organization structure is configured, you may want to make these internal repositories available to everyone on your Sourcegraph instance without relying on permission syncs. To mark all internal repositories as public, add the following field to the code host connection:

{
  // ...
  "markInternalReposAsPublic": true
}

When adding this configuration option, you may also want to configure your GitLab auth provider so that it does not sync user permissions for internal repositories.

Rate limits

Always include a token in a configuration for a GitLab.com URL to avoid being denied service by GitLab's unauthenticated rate limits.

When Sourcegraph hits a rate limit imposed by GitLab, Sourcegraph waits the appropriate amount of time specified by GitLab before retrying the request. This can be several minutes in extreme cases.

Internal rate limits

See Internal rate limits.

Configuration

admin/external_service/gitlab.schema.json 

{
	// If non-null, enforces GitLab repository permissions. This requires that there be an item in the `auth.providers` field of type "gitlab" with the same `url` field as specified in this `GitLabConnection`.
	"authorization": null,

	// TLS certificate of the GitLab instance. This is only necessary if the certificate is self-signed or signed by an internal CA. To get the certificate run `openssl s_client -connect HOST:443 -showcerts < /dev/null 2> /dev/null | openssl x509 -outform PEM`. To escape the value into a JSON string, you may want to use a tool like https://json-escape-text.now.sh.
	"certificate": null,
	// Other example values:
	// - "-----BEGIN CERTIFICATE-----\n..."

	// Only used to override the cloud_default column from a config file specified by EXTSVC_CONFIG_FILE
	"cloudDefault": false,

	// When set to true, this external service will be chosen as our 'Global' GitLab service. Only valid on Sourcegraph.com. Only one service can have this flag set.
	"cloudGlobal": false,

	// A list of projects to never mirror from this GitLab instance. Takes precedence over "projects" and "projectQuery" configuration. Supports excluding by name ({"name": "group/name"}) or by ID ({"id": 42}).
	"exclude": null,
	// Other example values:
	// - [
	//     {
	//       "name": "group/name"
	//     },
	//     {
	//       "id": 42
	//     },
	//     {
	//       "emptyRepos": true
	//     }
	//   ]
	// - [
	//     {
	//       "name": "gitlab-org/gitlab-ee"
	//     },
	//     {
	//       "name": "gitlab-com/www-gitlab-com"
	//     }
	//   ]

	// The type of Git URLs to use for cloning and fetching Git repositories on this GitLab instance.
	//
	// If "http", Sourcegraph will access GitLab repositories using Git URLs of the form http(s)://gitlab.example.com/myteam/myproject.git (using https: if the GitLab instance uses HTTPS).
	//
	// If "ssh", Sourcegraph will access GitLab repositories using Git URLs of the form [email protected]:myteam/myproject.git. See the documentation for how to provide SSH private keys and known_hosts: https://sourcegraph.com/docs/admin/repo/auth#repositories-that-need-http-s-or-ssh-authentication.
	"gitURLType": "http",

	// Deprecated and ignored field which will be removed entirely in the next release. GitLab repositories can no longer be enabled or disabled explicitly.
	"initialRepositoryEnablement": null,

	// If true, internal repositories will be accessible to all users on Sourcegraph as if they were public, and user permission syncs will no longer check for public repositories. This overrides repository permissions but allows easier discovery and access to internal repositories, and may be desirable if all users on the Sourcegraph instance should have access to all internal repositories anyways. Defaults to false.
	"markInternalReposAsPublic": false,

	// An array of transformations will apply to the repository name. Currently, only regex replacement is supported. All transformations happen after "repositoryPathPattern" is processed.
	"nameTransformations": null,
	// Other example values:
	// - [
	//     {
	//       "regex": "\\.d/",
	//       "replacement": "/"
	//     },
	//     {
	//       "regex": "-git$",
	//       "replacement": ""
	//     }
	//   ]

	// An array of strings specifying which GitLab projects to mirror on Sourcegraph. Each string is a URL path and query that targets a GitLab API endpoint returning a list of projects. If the string only contains a query, then "projects" is used as the path. Examples: "?membership=true&search=foo", "groups/mygroup/projects".
	//
	// The special string "none" can be used as the only element to disable this feature. Projects matched by multiple query strings are only imported once. Here are a few endpoints that return a list of projects: https://docs.gitlab.com/ee/api/projects.html#list-all-projects, https://docs.gitlab.com/ee/api/groups.html#list-a-groups-projects, https://docs.gitlab.com/ee/api/search.html#scope-projects.
	"projectQuery": [
		"none"
	],
	// Other example values:
	// - [
	//     "?membership=true\u0026search=foo",
	//     "groups/mygroup/projects"
	//   ]

	// A list of projects to mirror from this GitLab instance. Supports including by name ({"name": "group/name"}) or by ID ({"id": 42}).
	"projects": null,
	// Other example values:
	// - [
	//     {
	//       "name": "group/name"
	//     },
	//     {
	//       "id": 42
	//     }
	//   ]
	// - [
	//     {
	//       "name": "gnachman/iterm2"
	//     },
	//     {
	//       "name": "gitlab-org/gitlab-ce"
	//     }
	//   ]

	// Rate limit applied when making background API requests to GitLab.
	"rateLimit": {
		"enabled": true,
		"requestsPerHour": 36000
	},

	// The pattern used to generate a the corresponding Sourcegraph repository name for a GitLab project. In the pattern, the variable "{host}" is replaced with the GitLab URL's host (such as gitlab.example.com), and "{pathWithNamespace}" is replaced with the GitLab project's "namespace/path" (such as "myteam/myproject").
	//
	// For example, if your GitLab is https://gitlab.example.com and your Sourcegraph is https://src.example.com, then a repositoryPathPattern of "{host}/{pathWithNamespace}" would mean that a GitLab project at https://gitlab.example.com/myteam/myproject is available on Sourcegraph at https://src.example.com/gitlab.example.com/myteam/myproject.
	//
	// It is important that the Sourcegraph repository name generated with this pattern be unique to this code host. If different code hosts generate repository names that collide, Sourcegraph's behavior is undefined.
	"repositoryPathPattern": "{host}/{pathWithNamespace}",

	// A GitLab access token with "api" scope. Can be a personal access token (PAT) or an OAuth token. If you are enabling permissions with identity provider type "external", this token should also have "sudo" scope.
	"token": null,

	// The OAuth token expiry (Unix timestamp in seconds)
	"token.oauth.expiry": null,

	// The OAuth refresh token
	"token.oauth.refresh": null,

	// The type of the token
	"token.type": "pat",

	// URL of a GitLab instance, such as https://gitlab.example.com or (for GitLab.com) https://gitlab.com.
	"url": null,
	// Other example values:
	// - "https://gitlab.com"
	// - "https://gitlab.example.com"

	// An array of webhook configurations
	"webhooks": null
}

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"
  // ...
}

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.