Skip to main content

​
Connect to GitLab Server

The instructions below will work for on-prem instances that the Glean Crawler can access. Glean supports deployments on both GCP and AWS. Your on-prem GitLab Server instance must be network-accessible to the Glean crawler running in your cloud. Please reach out to Glean Support for any network configuration required.
Code Search is enabled by default after GitLab Server is connected to Glean. The previous code action toggle in the Admin console has been removed. See Code Search for more details.

​
Step 1. Determine API access token scopes

To authorize our API calls, we need a personal access token from a GitLab admin account. This account must have access to all projects that you’d like Glean to crawl. For this API token, if you’re willing to grant us the api scope, we can programmatically create webhooks during setup. If you want to restrict the token to read-only access, you will need to manually create webhooks for every single project that you want crawled. Supported Objects: GitLab Server connector supports merge requests, issues, wikis, commit messages, and code (for use in Glean Assistant).

​
Step 2. Create a personal access token

  1. Sign in to your GitLab admin account.
  2. Navigate to the upper right hand corner (user icon) and click “Preferences”
  3. Select “Access Tokens” on the left side menu.
  4. Add a personal access token.
    • Name: Glean Token
    • Scopes:
      • if you’re allowing write privileges
        • api
      • if you’re only allowing read privileges:
        • read_user
        • read_api
        • read_repository
  5. Leave Expires at empty
  6. Copy the personal access token into the corresponding field in Glean
  7. Check the box if the token has write privileges

​
Step 3. Provide information about your GitLab server instance

  1. Your GitLab instance domain name (e.g. https://gitlab.company.com)
  2. Your GitLab Server IP
If you provided api scope for the token, click Save and you’re done! Otherwise, move on to the next step.

​
Step 4. Create Webhooks Manually (if token has only read access)

If your personal access token does not have the api scope, you must configure webhooks so GitLab Server can send change events to Glean. Log in to GitLab with an admin account that can configure webhooks. Prerequisites:
  • For group webhooks, you must have the Owner role for the group.
  • For project webhooks, you must have at least the Maintainer role for the project.
Group webhooks (recommended) apply to all projects within a group and its subgroups, while project webhooks apply only to individual projects.
For each group or project you want Glean to handle events for:
  1. Navigate to the group or project page within GitLab.
  2. From the left-side menu, go to Settings → Webhooks**.
  3. Select Add new webhook.
  4. Configure the webhook:
    • URL: Use the URL shown in the GitLab data source setup page in Glean (Show setup instructions).
    • Secret token: Use the token as shown in the setup instructions.
    • Triggers:
      • Comments
      • Issue events
      • Merge request events
      • Wiki page events
  5. Save the webhook.
  6. In Glean, enter the same secret token in the Webhook secret token field for the GitLab Server data source.

​
System Hook

Lastly, create a system hook so Glean receives certain repository-level events:
  1. In GitLab, navigate to Admin Area → System Hooks.
  2. Create a system hook with:
    • URL: Use the URL shown in the GitLab data source setup page in Glean (Show setup instructions).
    • Secret token: Use the same token you used for the webhooks.
    • Triggers:
      • Repository update events
      • Merge request events
  3. Save the system hook.
Repository content changes (code pushes) are handled by incremental git crawls, so you do not need to enable Push events on webhooks or system hooks.

​
Step 5. Upload User Mapping to GCS

GitLab doesn’t return a user’s email via the API unless that user has explicitly allowed their email to be publicly shown. In order for us to correctly crawl permissions in GitLab, we need to be able to map each user id to their company email.
  1. Please create a CSV with two columns: GitLab user ID, and email. The CSV doesn’t need to have column headers, but the columns do need to be in the order (user ID, email).
    1. Note that the user ID is NOT the username –– the user ID should be numbers only and corresponds to the id in the example response of the /members API.
    2. Example of a correct row: 12345,user1@glean.com
  2. Provide this CSV to your Glean support team to correctly map the user IDs to the primary SSO email.
To list all gitlab user IDs, you can use the GitLab API. For your company emails, they can hopefully be queried from an identity system like Okta, Gsuite, or any other source you may have internally.

​
Appendix

If you want to direct webhooks through local network, before creating webhooks, we’ll need to allow local requests to the local network from web hooks and services:
  1. Navigate to Admin Area → Settings → Network
  2. Expand Outbound requests
  3. Paste the local proxy IP into the text box under “Local IP addresses and domain names that hooks and services may access.” (Glean Support can help you with finding this IP)
  4. Click Save changes
Network Settings