CI/CD features require a Paradime Bolt subscription.
How your Git provider starts the runs
On GitHub and GitLab, Paradime receives pull request and merge request events itself. You don’t add a CI file or an API key. On Azure DevOps and Bitbucket, a pipeline in your repository calls the Bolt API.
With the native setup, you also get chains, the merge queue,
@paradime comments on the pull request, and DinoAI Code Review. Without a GitLab connection, you can still start runs from a GitLab pipeline.
Capabilities
Turbo CI
Build and test only your changed models on every pull request, in a temporary schema, before they merge. Natively on GitHub and GitLab, and through a pipeline on Azure DevOps and BitBucket.Continuous Deployment
Run a Bolt schedule when changes are merged. Natively on GitHub and GitLab, and through a pipeline on Azure DevOps and BitBucket.Chains
Run several Turbo CI or on-merge schedules in the order you choose, on GitHub and GitLab. Each step starts only after the step before it passes, so a failure stops the rest of the chain.Lineage Diff Analysis
See the downstream impact of your changes directly in the pull request. The lineage diff report identifies changed columns in your dbt™ models and lists every downstream object affected, including other models and BI-layer nodes. Natively on GitHub and GitLab, and through a pipeline on Azure DevOps and BitBucket.Deferral and state comparison
Both Turbo CI and Continuous Deployment can defer to a previous run so they build only what changed. Setdeferred_schedule_slug to the slug of the production schedule to compare against. Paradime reads that schedule’s most recent successful run’s manifest.json (unless you set successful_run_only: false) to determine the new and modified resources. To compare against a whole Bolt environment instead of one schedule, set defer_environment_slug to the environment’s slug. See Defer to an environment. Your commands can then use the state:modified+ selector to build only the changed models and their downstream dependencies: