Official

Premium

GitLab

The CloudQuery GitLab plugin pulls configuration out of GitLab resources and loads it into any supported CloudQuery destination

Publisher

cloudquery

Latest version

v7.5.1

Type

Source

Platforms

Date Published

October 30, 2024

Price per 1M rows

Starting from $15

monthly free quota

1M rows

Documentation Tables Changelog Destinations

Overview Configuration

Set up process #

brew install cloudquery/tap/cloudquery

1. Download CLI and login

See installation options

2. Create source and destination configs

Plugin configuration

cloudquery sync gitlab.yml postgresql.yml

3. Run the sync

CloudQuery sync

Overview #

GitLab Source Plugin

The CloudQuery GitLab plugin pulls configuration out of GitLab resources and loads it into any supported CloudQuery destination (e.g. PostgreSQL, BigQuery, Snowflake, and more).

Authentication #

In order for CloudQuery to sync resources from your GitLab setup, you will need to use one of the supported authentication methods. More details on each method are provided in the configuration reference section.

Configuration #

GitLab Source Plugin Configuration Reference

Example #

This example syncs from GitLab to a Postgres destination, using API Key authentication. The (top level) source spec section is described in the Source Spec Reference.

kind: source
# Common source-plugin configuration
spec:
  name: gitlab
  path: cloudquery/gitlab
  registry: cloudquery
  version: "v7.5.1"
  tables: ["gitlab_users"]
  destinations: ["postgresql"]

  # Gitlab specific configuration
  # Learn more about the configuration options at https://cql.ink/gitlab_source
  spec:
    # required
    access_token: "${GITLAB_ACCESS_TOKEN}"
    # optional, leave empty for GitLab SaaS
    # base_url: "<INSTANCE_URL>"

See tables for a list of supported tables.

GitLab Spec #

This is the (nested) spec used by the GitLab source plugin:

auth_method (string) (optional, default: api_key)
This plugin supports different authentication methods when communicating with the GitLab API. Depending on the chosen authentication method, additional configuration parameters are required.
Supported values are api_key and bearer_token. If the api_key method is selected, the following additional configuration parameters will be used. If the bearer_token method is selected, the following additional configuration parameters will be used.
base_url (string, optional): URL for your self hosted GitLab server. Leave empty for GitLab SaaS. Not all tables are supported for GitLab SaaS.
concurrency (integer, optional, default: 10000) A best effort maximum number of Go routines to use. Lower this number to reduce memory usage.
scheduler (string, optional, default: dfs) The scheduler to use when determining the priority of resources to sync. Supported values are dfs (depth-first search), round-robin, shuffle and shuffle-queue.
For more information about this, see performance tuning.

API Key Configuration Reference #

access_token (string, required): An access token for your GitLab server. For instructions on how to generate an access token visit the GitLab docs.

Bearer Token Configuration Reference #

To use this authentication method, you will need an OAuth 2.0 application.

bearer_token (string) (required)
The OAuth 2.0 Bearer Token to authenticate with (recommendation: Use environment variable instead of hardcoded the token in the config).