Skip to main content

Check out Port for yourself 

Installation

This page will help you install Port's GitLab integration (powered by the Ocean framework).

This page outlines the following steps:

  • How to create a GitLab group access token to give the integration permissions to query your GitLab account.
  • How to configure and customize the integration before deploying it.
  • How to deploy the integration in the configuration that fits your use case.
OAuth2 Installation

Port's GitLab integration supports OAuth2 for quick installation, see OAuth2 installation for more information.

Prerequisites​

  • A GitLab account with admin privileges.
  • A GitLab group account with the api scope.
  • Your Port user role is set to Admin.

Setup​

Create a GitLab group access token​

A group access token can be used for the group it was generated at, as well as for all sub-groups underneath it.

The GitLab integration is able to query multiple GitLab root groups. To do so, it will require multiple group access tokens, each at the correct root group.

GitLab group access tokens example

For example, let's assume the following GitLab account structure:

GitLab account
.
├── microservices-group
│   ├──microservice1-group
│   └──microservice2-group
├── apis-group
│   ├── rest-api-group
│   └── graphql-api-group

In this example:

  • To map only the microservices-group, we require one group access token - one for the microservices-group.
  • To map the microservices-group and all of its subgroups, we require only one group access token - one for the microservices-group.
  • To map the microservices-group, the apis-group and all of their subgroups, we require only two group access tokens - one for the microservices-group and one for the apis-group.
  • To map the microservice1-group, we have 2 options:
    • Create a group access token for the microservices-group and use the token mapping to select just the microservice1-group.
    • Create a group access token for the microservice1-group directly.

See the Token Mapping section for more information.

The following steps will guide you how to create a GitLab group access token.

  1. Sign in to GitLab and go to your desired group's settings page:

  2. In the "Access Tokens" section, you need to provide the token details, including the name and an optional expiration date. Additionally, select the api scope, and then proceed to click on the "Create access token" button.

  3. Click "Create group access token".

  4. Copy the generated token and use it when deploying the integration in the following steps.

Token Mapping​

The GitLab integration supports fetching data related to specific paths in your GitLab groups. The integration is also able to fetch data from different GitLab parent groups by providing additional group tokens. In order to do so, you need to map the desired paths to the relevant access tokens. The tokenMapping parameter supports specifying the paths that the integration will search for files and information in, using globPatterns.

Mapping format:

{"MY_FIRST_GITLAB_PROJECT_GROUP_TOKEN": ["**/MyFirstGitLabProject/**","**/MySecondGitLabProject/*"]}

Example:

{"glpat-QXbeg-Ev9xtu5_5FsaAQ": ["**/DevopsTeam/*Service", "**/RnDTeam/*Service"]}
Helm installation parameter

When using the tokenMapping parameter in the integration's Helm installation, make sure to escape the necessary characters, for example:

--set integration.secrets.tokenMapping="\{\"glpat-oh1YXc54pR4eofx6hYy5\": [\"**\"]\}"

Multiple GitLab group access tokens example:

{"glpat-QXbeg-Ev9xtu5_5FsaAQ": ["**/DevopsTeam/*Service", "**/RnDTeam/*Service"],"glpat-xF7Ae-vXu5ts5_QbEgAQ9": ["**/MarketingTeam/*Service"]}

Configure Realtime webhook events​

tip

The appHost parameter is used specifically to enable the real-time functionality of the integration.

If it is not provided, the integration will continue to function correctly. In such a configuration, to retrieve the latest information from the target system, the scheduledResyncInterval parameter has to be set, or a manual resync will need to be triggered through Port's UI.

In order for the GitLab integration to update the data in Port on every change in the GitLab repository, you need to specify the appHost parameter. The appHost parameter should be set to the url of your GitLab integration instance. In addition, your GitLab instance (whether it is GitLab SaaS or a self-hosted version of GitLab) needs to have the option to send webhook requests to the GitLab integration instance, so please configure your network accordingly.

The default webhook events behavior​

The GitLab integration supports listening to GitLab webhooks and updating the relevant entities in Port accordingly.

Supported webhooks are Group webhooks and System hooks.

As part of the installation process, the integration will create a webhook in your GitLab instance, and will use it to listen to the relevant events.

There are a few points to consider before deciding on which webhook to choose :

  • If you choose system hooks, the integration will create a single webhook for the entire GitLab instance. If you choose group webhooks, the integration will create a webhook for each root group in your GitLab instance, unless you provide the tokenGroupHooksOverrideMapping parameter- and then it will create a webhook for each specified group in this parameter.

  • The system hooks has much less event types than the group webhooks.

    • Group Webhooks supported event types:

      • push_events
      • issues_events
      • jobs_events
      • merge_requests_events
      • pipeline_events
      • releases_events
      • tag_push_events
      • subgroup_events
      • confidential_issues_events
      • user_remove_from_group
      • user_update_for_group
      • user_add_to_group

    • System Hooks supported event types:

      • push_events
      • merge_requests_events
      • repository_update_events

      This means that if you choose system hooks, the integration will not be able to update the relevant entities in Port on events such as issues_events, pipeline_events and etc.

  • Creating a system hook requires admin privileges in GitLab. Due to this, the integration supports that the system hook will be created manually, and the integration will use it to listen to the relevant events.

Specific Group Webhooks​

By default, if appHost is provided, the integration will create group webhooks for each root group in your GitLab instance. If you need to create webhooks only for specific groups, you should configure the tokenGroupHooksOverrideMapping parameter.

System Webhooks​

To create a system hook there are two options:

note

In both options you'll need to provide the useSystemHook parameter with the value true.

  1. Provide a token with admin privileges in GitLab using the tokenMapping parameter.
    • When choosing this option, the integration will create the system hook in your GitLab account automatically.
  2. Create the system hook manually
    • Follow the instructions for creating a system hook in GitLab here.
    • In the URL field, provide the appHost parameter value with the path /integration/system/hook. e.g. https://my-gitlab-integration.com/integration/system/hook.
    • From the Triggers section, the GitLab integration currently supports the following events:
      • push
      • merge_request

GitLab System Hook

Listen to specified groups​

the integration can support listening to webhooks on specified groups, by configuring the tokenGroupHooksOverrideMapping parameter. this parameter is not required, and when you don't use it, the integration will listen to all of the root groups (if not using useSystemHooks=true)

Mapping format:

{"MY_FIRST_GROUPS_TOKEN": {"groups:"{"MY_FIRST_GROUP_FULL_PATH": {"events": [CHOSEN_EVENT_TYPES]}, "MY_OTHER_GROUP_FULL_PATH": {"events": [CHOSEN_EVENT_TYPES]}}}}

Example:

{"glpat-QXbeg-Ev9xtu5_5FsaAQ": {"groups": {"path/to/my-first-group": {"events": ["push_events", "merge_requests_events]}, "path/to/my-other-group": {"events": ["pipelines_events"]}}}}

You can configure multiple tokens, and multiple groups per token (the token should have admin access to those groups), but there are some rules:

  • All of the tokens mentioned here must be contained in tokenMapping.
  • A "groups" key is required for each token.
  • All of the groups in all of the tokens must be non-hierarchical to each other, and not identical (duplicated).
  • The group path is the full path in gitlab. If a group path is incorrect, the webhook will not be created.
  • The events for each group must match the supported event types mentioned below. if you would like to have all the events provided in the webhook, you can use: {"events" = []}, but not eliminate this key completely, because it is required.

Deploy the GitLab integration​

Choose one of the following installation methods:

Using this installation option means that the integration will be hosted by Port, with a customizable resync interval to ingest data into Port.

Live event support

Currently, live events are not supported for integrations hosted by Port.
Resyncs will be performed periodically (with a configurable interval), or manually triggered by you via Port's UI.

Therefore, real-time events (including GitOps) will not be ingested into Port immediately.
Support for live events is WIP and will be supported in the near future.

Installation

This integration supports OAuth2 for quick installation with default settings.

  1. Go to the GitLab data source page in your portal.

  2. Under Select your installation method, choose Hosted by Port.

  3. Click Connect.
    This will prompt you to authorize Port and install the integration with the following default settings:

    • Resync interval: Every 2 hours.

    • Send raw data examples: Enabled.

    See the Application settings section below for descriptions of these settings.

Answers to common questions about OAuth integrations can be found here:

OAuth integrations FAQ (click to expand)

What permissions do I need to install the integration using OAuth2?

Any level of permission will work. However, the data fetched depends on the user’s access level:

  • If the user has admin-level access, Port will fetch all project data.
  • If the user has restricted access (e.g., only specific projects), Port will fetch data based on those permissions.

Are there any differences in the sync behavior between OAuth2 and custom token-based installation?

Token-Based Installation requires users to manually generate and provide tokens, offering control over permissions but increasing the risk of setup errors.
OAuth2 Installation automates the process, simplifying setup and reducing errors while aligning access levels with the user’s permissions.

Can multiple integrations use the same OAuth connection? Can multiple organizations use the same OAuth connection?

There is no limit to the number of OAuth connections you can create for integrations or organizations.

What is the level of permissions Port requests in the OAuth2 authentication flow, and why?

The exact permissions Port requests will appear when connecting the OAuth provider.
Port requests both read and write access so the secrets can be used later for running self-service actions (e.g., creating Jira tickets).

What happens if my integration shows an authorization error with the 3rd party?

OAuth tokens are refreshed automatically by Port, including before manual syncs.
If you encounter an HTTP 401 unauthorized error, try running a manual resync or wait for the next scheduled sync, and the issue will resolve itself. If the error persists, please contact our support team.

What happens if I delete an installation of OAuth2?

  • Deleting an OAuth2-based installation will not revoke access to the third-party service.
  • Port will delete the OAuth secret, which prevents it from utilizing the connection for future syncs.
  • If you reinstall the integration, you will need to reconnect OAuth.
  • Actions relying on the deleted secret (e.g., creating a Jira ticket) will fail until the secret is recreated or the integration is reinstalled.

Application settings

Every integration hosted by Port has the following customizable application settings, which are configurable after installation:

  • Resync interval: The frequency at which Port will ingest data from the integration. There are various options available, ranging from every 1 hour to once a day.

  • Send raw data examples: A boolean toggle (enabled by default). If enabled, raw data examples will be sent from the integration to Port. These examples are used when testing your mapping configuration, they allow you to run your jq expressions against real data and see the results.

Integration settings

Every integration has its own tool-specific settings, under the Integration settings section:

  • GitLab host: The host of the Gitlab instance. If not specified, the default will be https://gitlab.com.

  • Token mapping: Mapping of GitLab tokens to the group scopes to ingest data from into port.
    For example:
    {"THE_GROUP_TOKEN":["getport-labs/**", "GROUP/PROJECT PATTERN TO RUN FOR"]}.
    To create a group token, see the GitLab documentation.

  • Use system hook: If enabled, the integration will use a system hook instead of project hooks.
    For a list of available system hooks, see the GitLab documentation.

  • Token Group Hooks Override Mapping: Mapping of Gitlab tokens to groups in which to create webhooks with specific events, if not set, it will create webhooks containing all the events, and only on root groups.
    For example:
    {"THE_GROUP_ADMIN_TOKEN":{"GROUP1_FULL_PATH": {"events": ["merge-requests_events"]}, "GROUP2_FULL_PATH": {"events": ["push_events", "pipeline_events"]}}}.
    Supported event types:
    ["push_events", "merge_requests_events", "issues_events", "job_events", "pipeline_events", "releases_events", "tag_push_events", "subgroup_events", "confidential_issues_events"]

You can also hover over the ⓘ icon next each setting to see a description.

Port secrets

Some integration settings require sensitive pieces of data, such as tokens.
For these settings, Port secrets will be used, ensuring that your sensitive data is encrypted and secure.

When filling in such a setting, its value will be obscured (shown as ••••••••).
For each such setting, Port will automatically create a secret in your organization.

To see all secrets in your organization, follow these steps.

Port source IP addresses

When using this installation method, Port will make outbound calls to your 3rd-party applications from static IP addresses.
You may need to add these addresses to your allowlist, in order to allow Port to interact with the integrated service:

54.73.167.226  
63.33.143.237  
54.76.185.219