Site admins can sync Git repositories hosted on GitHub.com and GitHub Enterprise with Sourcegraph so that users can search and navigate the repositories.
To connect GitHub to Sourcegraph:
- Depending on whether you are a site admin or user:
- Site admin: Go to Site admin > Manage repositories > Add repositories
- User: Go to Settings > Manage repositories.
- Select GitHub.
- Configure the connection to GitHub 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.
NOTE: Adding code hosts as a user is currently in private beta.
- GitHub.com
- GitHub Enterprise v2.10 and newer
There are four fields for configuring which repositories are mirrored/synchronized:
repos
A list of repositories inowner/nameformat. The order determines the order in which we sync repository metadata and is safe to change.orgs
A list of organizations (every repository belonging to the organization will be cloned).repositoryQuery
A list of strings with three pre-defined options (public,affiliated,none, none of which are subject to result limitations), and/or a GitHub advanced search query. Note: There is an existing limitation that requires the latter, GitHub advanced search queries, to return less than 1000 results. See this issue for ongoing work to address this limitation.exclude
A list of repositories to exclude which takes precedence over therepos,orgs, andrepositoryQueryfields.
A token that has the prerequisite scopes is required in order to clone private repositories for search, as well as at least read access to the relevant private repositories.
See GitHub API token and access for more details.
The GitHub service requires a token in order to access their API. There are two different types of tokens you can supply:
- Personal access token:
This gives Sourcegraph the same level of access to repositories as the account that created the token. If you're not wanting to mix your personal repositories with your organizations repositories, you could add an entry to theexcludearray, or you can use a machine user token. - Machine user token:
Generates a token for a machine user that is affiliated with an organization instead of a user account.
No token scopes are required if you only want to sync public repositories and don't want to use any of the following features. Otherwise, the following token scopes are required for specific features:
| Feature | Required token scopes |
|---|---|
| Sync private repositories | repo |
| Sync repository permissions | repo |
| Repository permissions caching | repo, write:org |
| Batch changes | repo, read:org, user:email, read:discussion, and workflow (learn more) |
WARNING: In addition to the prerequisite token scopes, the account attached to the token must actually have the same level of access to the relevant resources that you are trying to grant. For example:
- If read access to repositories is required, the token must have
reposcope and the token's account must have read access to the relevant repositories. This can happen by being directly granted read access to repositories, being on a team with read access to the repository, and so on.- If write access to repositories is required, the token must have
reposcope and the token's account must have write access to all repositories. This can happen by being added as a direct contributor, being on a team with write access to the repository, being an admin for the repository's organization, and so on.- If write access to organizations is required, the token must have
write:orgscope and the token's account must have write access for all organizations. This can happen by being an admin in all relevant organizations.Learn more about how the GitHub API is used and what level of access is required in the corresponding feature documentation.
You should always include a token in a configuration for a GitHub.com URL to avoid being denied service by GitHub's unauthenticated rate limits. If you don't want to automatically synchronize repositories from the account associated with your personal access token, you can create a token without a repo scope for the purposes of bypassing rate limit restrictions only.
Internal rate limiting can be configured to limit the rate at which requests are made from Sourcegraph to GitHub.
If enabled, the default rate is set at 5000 per hour which can be configured via the requestsPerHour field (see below). If rate limiting is configured more than once for the same code host instance, the most restrictive limit will be used.
NOTE Internal rate limiting is only currently applied when synchronising changesets in batch changes, repository permissions and repository metadata from code hosts.
By default, all Sourcegraph users can view all repositories. To configure Sourcegraph to use GitHub's per-user repository permissions, see "Repository permissions".
To configure GitHub as an authentication provider (which will enable sign-in via GitHub), see the authentication documentation.
The webhooks setting allows specifying the organization webhook secrets necessary to authenticate incoming webhook requests to /.api/github-webhooks.
"webhooks": [
{"org": "your_org", "secret": "verylongrandomsecret"}
]Using webhooks is highly recommended when using batch changes, since they speed up the syncing of pull request data between GitHub and Sourcegraph and make it more efficient.
To set up webhooks:
- In Sourcegraph, go to Site admin > Manage repositories and edit the GitHub configuration.
- Add the
"webhooks"property to the configuration (you can generate a secret withopenssl rand -hex 32):
"webhooks": [{"org": "your_org", "secret": "verylongrandomsecret"}] - Click Update repositories.
- Copy the webhook URL displayed below the Update repositories button.
- On GitHub, go to the settings page of your organization. From there, click Settings, then Webhooks, then Add webhook.
- Fill in the webhook form:
- Payload URL: the URL you copied above from Sourcegraph.
- Content type: this must be set to
application/json. - Secret: the secret token you configured Sourcegraph to use above.
- Which events: select Let me select individual events, and then enable:
- Issue comments
- Pull requests
- Pull request reviews
- Pull request review comments
- Check runs
- Check suites
- Statuses
- Active: ensure this is enabled.
- Click Add webhook.
- Confirm that the new webhook is listed.
Done! Sourcegraph will now receive webhook events from GitHub and use them to sync pull request events, used by batch changes, faster and more efficiently.
GitHub connections support the following configuration options, which are specified in the JSON editor in the site admin "Manage repositories" area.
Sourcegraph displays search results from the default branch of a repository when no revision: parameter is specified. If you'd like the search results to be displayed from another branch by default, you may change a repo's default branch on the github repo settings page. If this is not an option, consider using search contexts instead.
When Sourcegraph syncs repositories configured via repositoryQuery, it consumes GitHub API search rate limit, which is lower than the normal rate limit. The affiliated, public and none special values, however, trigger normal API requests instead of search API requests.
When the search rate limit quota is exhausted, an error like failed to list GitHub repositories for search: page=..., searchString=\"...\" can be found in logs. To work around this try reducing the frequency with which repository syncing happens by setting a higher value (in minutes) of repoListUpdateInterval in your Sourcegraph [site config] (https://docs.sourcegraph.com/admin/config/site_config).
repositoryQuery is the only repo syncing method that consumes GitHub search API quota, so if setting repoListUpdateInterval doesn't work consider switching your syncing method to use another option, like orgs, or using one of the special values described above.
The repositoryQuery option "public" is valuable in that it allows sourcegraph to sync all public repositories, however, it does not return whether or not a repo is archived. This can result in archived repos appearing in normal search. You can see an example of what is returned by the GitHub API for a query to "public" here.
If you would like to sync all public repositories while omitting archived repos, consider generating a GitHub token with access to only public repositories, then use respositoryQuery with option affiliated and an exclude argument with option public as seen in the example below:
{
"url": "https://github.example.com",
"gitURLType": "http",
"repositoryPathPattern": "devs/{nameWithOwner}",
"repositoryQuery": [
"affiliated"
],
"token": "TOKEN_WITH_PUBLIC_ACCESS",
"exclude": [
{
"archived": true
}
]
}
GitHub's Search API only returns the first 1000 results. Therefore a repositoryQuery (other than the three pre-defined options) needs to return a 1000 results or less otherwise Sourcegraph will not synchronize some repositories. To workaround this limitation you can split your query into multiple queries, each returning less than a 1000 results. For example if your query is org:Microsoft fork:no you can adjust your query to:
{
// ...
"repositoryQuery": [
"org:Microsoft fork:no created:>=2019",
"org:Microsoft fork:no created:2018",
"org:Microsoft fork:no created:2016..2017",
"org:Microsoft fork:no created:<2016"
]
}
If splitting by creation date does not work, try another field. See GitHub advanced search query for other fields you can try.
See Handle GitHub repositoryQuery that has more than 1000 results for ongoing work to address this limitation.