Turbo CI on GitHub pull requests

Run Turbo CI on GitHub pull requests using Paradime’s native GitHub app. First complete the shared Turbo CI setup — the ci environment, the custom schema macro, and the Turbo CI job — then connect GitHub.

​

How Turbo CI works on GitHub

Paradime listens for pull request events from GitHub. Turbo CI runs on PR creation, reopening, and each new commit. When Paradime receives the webhook, Bolt triggers a run based on the Turbo CI job configuration. Models build into a temporary schema using the prefix paradime_turbo_ci_pr_ followed by the PR number (for example, paradime_turbo_ci_pr_123), and the run status shows on the pull request. After the PR is merged, Paradime deletes the temporary schema.

​

DinoAI Summary on failed runs

When a Turbo CI run fails on a pull request, Paradime posts a DinoAI Summary as a comment on the PR, so reviewers can see why CI failed without leaving GitHub or opening the run logs. The PR comment includes:

• The schedule name and commit SHA, with a link to view the full run in Paradime.
• A plain-language explanation of what went wrong (for example, which models failed and why).
• The list of errors with the affected model and the underlying error message.
• The exact command that failed (for example, dbt run --select state:modified+).

No configuration is required. The DinoAI Summary is posted automatically whenever a Turbo CI run fails on a pull request.

​

Schedule Parse check on pull requests

Alongside the main Turbo CI run, Paradime exposes a separate, lightweight GitHub check called Paradime Schedule Parse that validates your YAML schedule configuration on every PR that modifies it. It uses the same validation logic as the paradime bolt verify CLI command, but runs automatically in GitHub on the PR head commit. When it runs The check runs when a pull request is opened or updated and the PR changes a schedule file (scoped to your configured dbt™ root):

• The legacy flat file paradime_schedules.yml.
• Any .yaml or .yml file under the modular .bolt/ directory.

If the PR does not touch a schedule file, the check is skipped. What it checks The check reads the schedule file(s) at the PR head SHA via the GitHub Contents API (no clone, no Bolt run, no dbt™ execution) and validates that:

• Every schedule parses as valid YAML and matches the Bolt schedule schema.
• Every schedule individually validates (required fields present, references resolve), the same rules the deployer applies when YAML schedules are merged to your default branch.

Outcomes

• Passed — all schedules in the changed files are valid.
• Failed — the check output lists each failing schedule with its source file and the validation error. Every failure in the PR is reported.

​

Filter Turbo CI runs by PR number

Filter Turbo CI runs by pull request number to see all runs for a specific PR:

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

You can also see a run’s PR by hovering over the Pull Request field of a Turbo CI run.

​

Environment variables

Paradime provides system environment variables you can use to build custom macro or schema logic when a PR is opened:

​

View run logs

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