Lint and Test Code Changes On Pull Requests

This template creates a Turbo CI Bolt schedule with two commands. When a pull request is opened, it first runs your pre-commit hooks (linting, formatting, project checks) against only the files changed in the pull request, then runs the standard Turbo CI dbt™ command to build and test only the modified models and their downstream dependencies in a temporary schema.

Key Benefits

Enforce code quality (SQLFluff, dbt™ project checks) on every pull request, not just on developer machines
Lint only the files changed in the pull request, keeping runs fast
Build and test only modified models and their downstream dependencies
Run validation in a temporary schema to avoid impacting production
Get immediate feedback on pull request status through Paradime integration

Prerequisites

A pre-commit configuration (.pre-commit-config.yaml) at the root of your dbt™ repository, for example with SQLFluff hooks
A dedicated CI environment exists in Settings > Environments, with its own warehouse connection using a target named ci, and the schedule’s Environment is set to it
A CI pipeline in your Git provider triggers the Turbo CI schedule when a pull request opens. See the setup guide for GitHub, GitLab, Azure DevOps, or BitBucket.

Default Configuration

Schedule Settings

Setting	Value	Explanation
Schedule Type	`Turbo CI`	Enables automated validation of pull request changes.
Schedule Name	`turbo ci lint and run`	A descriptive name indicating the purpose of the schedule
Deferred Schedule	`hourly run`	Specifies the production schedule to compare against for state changes.
Git Branch	`main`	Uses your default production branch to ensure correct code comparison.

Command Settings

The template runs two commands in order:

A Run pre-commit command that lints only the files changed in the pull request:
pre-commit run --from-ref origin/main --to-ref HEAD
The --from-ref / --to-ref flags tell pre-commit to check only the files that differ between your base branch and the pull request commit, mirroring how pre-commit behaves locally on staged files.
The standard Turbo CI dbt™ command that builds and tests only the modified models and their downstream dependencies:
dbt build --select state:modified+

By default, if the pre-commit command fails, the dbt™ command is skipped and the run is marked as failed. To still build and test models when linting fails, set continue_on_error on the pre-commit command.

Trigger Type

Type: Scheduled Run (Cron)
Cron Schedule: OFF (This schedule will be triggered by a new pull request event, not a cron schedule)

For custom Trigger configurations, see Trigger Types documentation.

Notification Settings

Email Alerts:
- Success: Confirms hooks passed and models built and tested successfully
- Failure: Alerts when a hook fails, models fail to build, or tests fail
- SLA Breach: Alerts if the run takes longer than 120 minutes

For custom notification configurations, see Notification Settings documentation.

Full Example

pre-commit configuration

Add a .pre-commit-config.yaml at the root of your dbt™ repository. This example combines SQLFluff linting with dbt-checkpoint model and script checks:

.pre-commit-config.yaml

repos:
  # SQL linting using SQLFluff
  - repo: https://github.com/sqlfluff/sqlfluff
    rev: 3.3.0
    hooks:
      - id: sqlfluff-lint
        name: SQLFluff Lint
        description: Lints SQL files using SQLFluff
        files: ^.*\.sql$
        additional_dependencies: ["sqlfluff-templater-dbt"]
        args: ["--dialect", "snowflake", "--templater", "dbt"]

  # dbt™ specific checks using dbt-checkpoint
  - repo: https://github.com/dbt-checkpoint/dbt-checkpoint
    rev: v2.0.6
    hooks:
      - id: dbt-parse
      - id: check-model-has-description
        name: Check Model Descriptions
        description: Ensures models have descriptions
      - id: check-model-has-tests
        name: Check Model Tests
        description: Ensures models have minimum test coverage
        args: ["--test-cnt", "2"]
      - id: check-script-has-no-table-name
        name: Check Script Table References
        description: Ensure only source() or ref() macros are used for table references
        files: models/.*\.sql$
      - id: check-script-ref-and-source
        name: Check Script References
        description: Validate all ref() and source() references exist
        files: models/.*\.sql$
        args: [--manifest, target/manifest.json]

# Define what files to exclude from all hooks
exclude: |
  (?x)^(
      target/.*|
      logs/.*|
      .*/snapshots/.*|
      tests/.*_test\.sql|
      analysis/.*
  )$

Set the SQLFluff --dialect to your warehouse (for example bigquery, snowflake, or redshift). The dbt-parse hook runs first so that checks needing target/manifest.json, like check-script-ref-and-source, have a fresh manifest to validate against.

This schedule is the enforcement point for these hooks, so no local setup is needed. Developers can also run the same checks on demand from the Code IDE terminal with paradime pre-commit. See Paradime Setup and Configuration.

Schedule configuration

The equivalent Schedules as Code definition for the Turbo CI schedule:

paradime_schedules.yml

schedules:
  - name: turbo ci lint and run
    environment: tagging-iguana-qhhi5i     # Your CI environment's slug, shown in Settings > Environments
    git_branch: main
    commands:
      - pre-commit run --from-ref origin/main --to-ref HEAD
      - dbt build --select state:modified+
    schedule: 'OFF'
    turbo_ci:
      enabled: true
      deferred_schedule_slug: hourly-run   # Production schedule to compare state against
      successful_run_only: true
    sla_minutes: 120
    notifications:
      emails:
        - address: data-team@acme.io
          events:
            - passed
            - failed
            - sla

When to Customize

Tailor this template to your specific needs:

Choose your hooks in .pre-commit-config.yaml: SQLFluff for SQL linting, Prettier for YAML and Markdown formatting, or any other pre-commit hook your team uses.
Run a single hook instead of the full suite by using pre-commit run <hook-id> --from-ref origin/main --to-ref HEAD, or check the whole project with pre-commit run --all-files.
Adjust the base branch in --from-ref if your pull requests target a branch other than main.
Adjust Deferred Schedule to the production schedule you want Turbo CI to compare against for state changes.
Modify command settings with the dbt™ commands to suit your testing requirements, such as running specific model selectors or additional tests.
Add more notification destinations (Slack, MS Teams) to match your team’s workflows.
Customize Temporary Schema Naming via the dbt™ generate_schema_name.sql macro to handle the temporary schema prefix.

Foundations

Automate with AI agents

Set up & configure

Orchestrate data pipelines

Migrate to Paradime

Develop in Paradime

Learn dbt™

Lint and Test Code Changes On Pull Requests

Default Configuration

Schedule Settings

Command Settings

Trigger Type

Notification Settings

Full Example

pre-commit configuration

Schedule configuration

When to Customize

​Default Configuration

​Schedule Settings

​Command Settings

​Trigger Type

​Notification Settings

​Full Example

​pre-commit configuration

​Schedule configuration

​When to Customize

Default Configuration

Schedule Settings

Command Settings

Trigger Type

Notification Settings

Full Example

pre-commit configuration

Schedule configuration

When to Customize