Chain Turbo CI checks to run in order

​

Steps

1

Choose the order of the steps

The first step of the chain starts when a pull request opens or gets a new commit. Each later step starts after the step before it finishes. Put the fastest and cheapest check first:

1. CI - lint runs pre-commit on the changed files.
2. CI - dbt build builds and tests the changed models.

All the steps run on the latest commit of the pull request, in the same temporary schemas (paradime_turbo_ci_pr_ followed by the pull request number). A later step can use the tables that an earlier step built.

2

Link the later step to the step before it

In Bolt, open the CI - dbt build schedule and select Edit. In Trigger type, keep Turbo CI selected, then:

1. Turn on Run after another schedule.
2. In Bolt schedule name, select CI - lint. The list shows only the schedules in the current workspace.
3. Under Bolt schedule complete with status:, select Passed.

Select Deploy. The link applies from the next pull request event.

To run a step only when the step before it fails, for example to post a message, select Failed instead of Passed.

3

Add more steps (optional)

Link each extra step in the same way, and select the step that comes before it. If two steps run after the same step, both start at the same time when that step finishes.

The step before must be a Turbo CI schedule with the same Git branch. Otherwise, the later step is not part of the chain, and it starts as soon as the pull request opens.

4

Require only the overall check on GitHub

In your GitHub repository, go to Settings > Branches and edit the protection rule for your base branch. Under Require status checks to pass before merging, require Paradime Turbo CI only.Paradime Turbo CI holds the result of the whole chain. Do not require the Paradime Turbo CI / <schedule name> checks: their names change when you edit the chain, and GitHub blocks the merge while a required check is missing.

5

Push a commit to a pull request

Change a model in your dbt™ project folder, then open a pull request or push a commit to an open one. The pull request must not be a draft.

​

Re-run a failed step

• From GitHub: select Re-run on the check of the failed step. If you select Re-run on a skipped step, Paradime runs the failed step before it first.
• From Paradime: open the run of the failed step, select Retry, and then Retry this step. To run all the steps again from the first one, select Retry the whole chain.

​

How the chain behaves

• A new commit restarts the chain. Paradime cancels the steps that run on the previous commit and starts again from the first step.
• A failure stops the chain. The steps after the failed step are skipped. If other steps of the same chain are running, Paradime cancels them.
• Closing the pull request stops the chain. Converting it to a draft also cancels its runs. When you reopen it, or mark it ready for review, the chain starts again.
• A suspended step is skipped, and so are the steps after it.
• A chain can run for 12 hours. After that, Paradime cancels the steps that are still running.

​

Set it up in YAML

schedules:
  - name: "CI - lint"
    description: "Lint the files that the pull request changes"
    owner_email: data-platform@acme.io
    environment: ci                                  # your CI environment's slug
    git_branch: main
    schedule: "OFF"
    commands:
      - pre-commit run --from-ref origin/main --to-ref HEAD
    turbo_ci:
      enabled: true
      deferred_schedule_slug: prod-nightly-a7c2e9    # your production schedule's slug
      successful_run_only: true

  - name: "CI - dbt build"
    description: "Build and test the changed models after linting passes"
    owner_email: data-platform@acme.io
    environment: ci
    git_branch: main
    schedule: "OFF"
    commands:
      - dbt build --select state:modified+
    turbo_ci:
      enabled: true
      deferred_schedule_slug: prod-nightly-a7c2e9
      successful_run_only: true
    run_after:
      schedule: "CI - lint"                          # the step before this one
      "on": [passed]                                 # passed, failed, or both

​

Next steps

​

Troubleshooting

• Both checks start at the same time. The later step has no link, or its link names a schedule that is not a Turbo CI schedule for the same Git branch. If you use YAML, the change applies only after it merges and Bolt deploys your schedules.
• A step never starts. The step before it did not finish with the status you selected, or it was skipped. Open the check of the step before it to see its result.
• Re-run does nothing. A step of the chain is still running, the pull request has a newer commit, or the pull request is closed or a draft. On the run page in Paradime, Retry shows the reason.