> ## Documentation Index
> Fetch the complete documentation index at: https://docs.paradime.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Chain Turbo CI checks to run in order
> Run Turbo CI schedules one after another on each pull request, so a failed lint check stops the dbt™ build, and re-run a failed step from GitHub.
Make a Turbo CI schedule wait for another one on the same pull request. In this guide, the `CI - dbt build` check starts only after the `CI - lint` check passes, so Paradime does not build models for a pull request that fails linting.
**Prerequisites**
* The [Paradime GitHub app](/integrations/github/github-app) installed on your dbt™ repository. Chains work only with the app.
* [Turbo CI set up](/guides/orchestrate-data-pipelines/set-up-turbo-ci): a CI environment, the custom schema macro, and a production schedule to defer to.
* Two Turbo CI schedules for the same base branch, for example `CI - lint` and `CI - dbt build`. To create them, see [Run several Turbo CI checks on a pull request](/guides/orchestrate-data-pipelines/run-several-turbo-ci-checks).
* The Admin or Developer [role](/products/settings/users/roles-and-permissions) in Paradime, to edit Bolt schedules.
Estimated time: 10 minutes.
## 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.
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**.
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.
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 / ` checks: their names change when you edit the chain, and GitHub blocks the merge while a required check is missing.
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.
On the pull request, `Paradime Turbo CI / CI - dbt build` stays queued with `Waiting for CI - lint` until the lint check passes, and then it runs. If the lint check fails, the build check shows `Skipped: CI - lint failed`, and `Paradime Turbo CI` fails with `0 of 2 passed · failed: CI - lint`.
If both checks start at the same time, the link is not in place. Open `CI - dbt build` and make sure that **Run after another schedule** is on and names `CI - lint`, then push a new commit.
## Re-run a failed step
If a step fails for a reason outside your code, for example a warehouse timeout, run the failed step and the steps after it again on the same commit. The steps before it keep their results.
* **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**.
You can re-run a step only after every step on the pull request finishes. If you push a new commit, the whole chain runs again on it, so you do not need to re-run. You cannot retry a chain step with the API, the CLI, or the Python SDK, because the steps after it would not run.
## 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
If you manage your schedules as code, add `run_after` to each later step. This file defines the same two-step chain:
```yaml paradime_schedules.yml theme={"system"}
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
```
Keep the quotes around `on`. YAML reads a bare `on` as the boolean `true`, and then the schedule file fails to parse.
Run `paradime schedule verify` (Paradime CLI 6.8.0 or later) before you commit. It checks the file, adds a `slug` to each new schedule, and adds the matching `schedule_slug` under `run_after`. Paradime reads chains from your deployed schedules, so a pull request that changes a chain applies after it merges and Bolt deploys your schedules. See [Manage schedules as code](/guides/orchestrate-data-pipelines/manage-schedules-as-code).
## Next steps
Deploy your changes, then run the jobs that depend on the deploy.
Every rule for pull request and merge chains, and what GitHub shows.
The trigger settings that link one step to the next.
How Retry works for chain steps and for other runs.
## 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.
## Related topics
- [Run Bolt schedules in order on pull requests and merges](/products/bolt/ci-cd/chains.md)
- [Run several Turbo CI checks on a pull request](/guides/orchestrate-data-pipelines/run-several-turbo-ci-checks.md)
- [Lint and Test Code Changes On Pull Requests](/guides/orchestrate-data-pipelines/templates/ci-cd-templates/lint-and-test-code-changes-on-pull-requests.md)
- [Run Turbo CI and merge schedules in order](/changelog/2026-10-08/ci-cd-chains.md)
- [Turbo CI for dbt™ pull requests](/products/bolt/ci-cd/turbo-ci/index.md)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.