Turbo CI on GitLab merge requests

Run Turbo CI on GitLab merge requests. First complete the shared Turbo CI setup: the ci environment, the custom schema macro, and the Turbo CI schedule. Then choose how GitLab starts the runs:

With the GitLab connection (recommended): Paradime receives merge request events and runs your Turbo CI schedules. You do not need a pipeline or an API key.
From a GitLab pipeline: your .gitlab-ci.yml calls the Bolt API. Use this if you don’t use the GitLab connection.

Run Turbo CI with the GitLab connection

Prerequisites

Connect GitLab on gitlab.com or GitLab Self-Managed, and pick your dbt™ project as one of the connection’s projects. Your workspace can keep its deploy key, or clone over HTTPS.
Complete the shared Turbo CI setup.

How Turbo CI works on GitLab

A GitLab pipeline for a merge request commit, with an external stage that holds the Paradime Lineage Diff and Paradime Turbo CI statuses, both passed

Turbo CI runs when a merge request opens or reopens, when it gets a new commit, and when it leaves draft. Paradime runs only when the merge request changes files in your dbt™ project. Models build into a temporary schema named paradime_turbo_ci_pr_ followed by the merge request number, for example paradime_turbo_ci_pr_123. When the merge request is merged or closed, Paradime deletes the temporary schema.

Each Turbo CI schedule posts its own commit status on the merge request, and Paradime Turbo CI holds the overall result. GitLab shows the statuses as an external pipeline on the commit. When several Paradime workspaces use the same project, each status name ends with / and the workspace name. To run the schedules in order, see Chains.
A draft merge request does not run Turbo CI. If a merge request becomes a draft, or is merged or closed, Paradime stops its running chain.
To re-run a failed step, retry the run from Bolt, or comment @paradime retry on the merge request. See Mention Paradime in a merge request.
When a Turbo CI run fails, Paradime posts a DinoAI summary of the failure as a note on the merge request, like the DinoAI Summary on GitHub.

Filter Turbo CI runs by merge request number

Open Bolt and select the Turbo CI schedule.
In the schedule’s Run history, enter the merge request number in the search box, for example PR:183.

Environment variables

Runs that the GitLab connection starts get these system environment variables, which you can use in custom macro or schema logic:

Variable name	Example	Value
`PARADIME_TURBO_CI_PREFIX`	`paradime_turbo_ci_pr_123`	The temporary schema prefix for the merge request.
`PR_NUMBER`	`123`	The merge request number (its IID in the project).
`GITHUB_PR_NUMBER`	`123`	The same merge request number. The name is kept for schedules shared with GitHub.

Run Turbo CI from a GitLab pipeline

GitLab merged results pipelines require the Premium or Ultimate tier. Enable merged results pipelines before continuing.

Generate API keys

To trigger the Turbo CI schedule from your pipeline, generate a Paradime API key with the Bolt schedules admin capability. Generate an Account API key (a prdm_cmp_... Bearer token) and save the token, your workspace token, and the API endpoint; you will add them as CI/CD variables in the next step.

Generate API keys

Create a GitLab pipeline

Create a .gitlab-ci.yml file at the root of your dbt™ repository and enter the values required.

.gitlab-ci.yml

# Define the stages of the pipeline - in this case, just one stage for CI
stages:
 - paradime_turbo_ci

# Main job definition
paradime_turbo_ci:
  # Specify which stage this job belongs to
  stage: paradime_turbo_ci

  # Use Python 3.11 as the base Docker image for this job
  image: python:3.11

  # Define when this pipeline should be triggered
  rules:
    # This job will run when a merge request event occurs (MR opened or updated)
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
      when: always

  # Define environment variables needed for the job
  variables:
    # These variables should be configured in GitLab CI/CD settings
    PARADIME_WORKSPACE_UID: ${PARADIME_WORKSPACE_UID}           # Workspace token (workspace UID)
    PARADIME_API_SECRET: ${PARADIME_API_SECRET}     # Account API key (prdm_cmp_...)
    PARADIME_API_ENDPOINT: ${PARADIME_API_ENDPOINT} # Paradime API endpoint URL
    PARADIME_SCHEDULE_SLUG: "flowing-pachy-wyy4fs"  # Slug of the Paradime schedule to run
  before_script:
    # Install the Paradime Python SDK
    - pip install paradime-io

  script:
    # Get the merge request number and commit SHA from GitLab predefined variables
    - export MR_NUMBER=$CI_MERGE_REQUEST_IID
    - echo "Merge Request Number: $MR_NUMBER"
    - echo "Commit SHA: $CI_COMMIT_SHA"
    # Run the Turbo CI schedule for this PR and wait for completion
    - paradime bolt run "$PARADIME_SCHEDULE_SLUG" --branch ${CI_COMMIT_SHA} --pr-number $MR_NUMBER --wait

  timeout: 60 minutes

Add the variables in GitLab

Add these as GitLab CI/CD variables:

PARADIME_API_SECRET — your account API key (prdm_cmp_...)
PARADIME_WORKSPACE_UID — your workspace token
PARADIME_API_ENDPOINT

View run logs

Inspect the run logs for each Turbo CI run like any other Bolt schedule.

Schedule Anatomy

Deploy Schedules

Managing Schedules

CI/CD

Turbo CI on GitLab merge requests

Run Turbo CI with the GitLab connection

How Turbo CI works on GitLab

Filter Turbo CI runs by merge request number

Environment variables

Run Turbo CI from a GitLab pipeline

Generate API keys

Generate API keys

Create a GitLab pipeline

Add the variables in GitLab

View run logs

Run details

​Run Turbo CI with the GitLab connection

​How Turbo CI works on GitLab

​Filter Turbo CI runs by merge request number

​Environment variables

​Run Turbo CI from a GitLab pipeline

​Generate API keys

Generate API keys

​Create a GitLab pipeline

​Add the variables in GitLab

​View run logs

Run details

Run Turbo CI with the GitLab connection

How Turbo CI works on GitLab

Filter Turbo CI runs by merge request number

Environment variables

Run Turbo CI from a GitLab pipeline

Generate API keys

Create a GitLab pipeline

Add the variables in GitLab

View run logs