Slimmer CI
Automatically validate dbt changes on every pull request. Slimmer CI runs only the modified models and their downstream dependents, giving fast, targeted feedback directly on your PR.
How It Works
When a developer opens or updates a pull request, Slimmer CI:
- Auto-triggers on PR open/push across all supported Git providers
- Detects changed models by comparing the PR branch against the production manifest
- Builds into an isolated schema so PR changes never touch production data
- Runs only what changed plus downstream dependents (no full-project rebuilds)
- Reports results as a commit status on the PR (pass/fail gate)
- Posts schema diffs and an AI review comment showing exactly what changed
The result: reviewers see the impact of code changes before merging, and broken models never reach production.
Key Features
Automatic Triggering
Slimmer CI triggers automatically on every PR open and push event. No manual "Run" button needed. When the runner is enabled for a project, any new commit on a PR immediately enqueues a CI build. Rapid pushes are coalesced so only the latest commit is built.
When a PR is closed without merging, any CI build still running for it is cancelled automatically, so abandoned PRs never keep consuming build capacity.
You can also cancel a run yourself. Any active run shows a Cancel button on its detail, and cancelling stops the in-progress dbt build promptly rather than letting it run to completion, so a run you kicked off by mistake or no longer need frees up capacity right away.
GitHub App Connection
For GitHub projects, Slimmer CI shows a connection panel that tells you exactly which repositories the dbdeux GitHub App can see. At a glance you know whether the App is installed and whether it covers the repository you are working in, with a direct link to install or adjust its repository access. This removes the usual guesswork of "is CI actually wired up to this repo?"
PR-Isolated Build Schema
Each PR run builds into a dedicated, ephemeral schema in your warehouse. This means:
- PR builds never write to production tables
- Concurrent PRs do not interfere with each other
- The schema is cleaned up automatically after the run completes
State-Aware Builds
Slimmer CI uses dbt's state comparison (state:modified+) against the latest production manifest. This means:
- Only modified models and their downstream dependents are built
- Unchanged models are skipped entirely
- Typical CI runs complete in seconds, not minutes
- dbt variables from the target environment are injected automatically, so CI builds use the same
--varsas your scheduled runs
Schema Diff on PRs
Every Slimmer CI run automatically compares the schema output of modified models:
| Change Type | What it shows |
|---|---|
| Columns added | New columns that will appear in the warehouse |
| Columns removed | Columns that will be dropped |
| Type changes | Data type modifications |
| Downstream impact | How many downstream models are affected |
Severity badges highlight breaking changes (removals, type changes) vs additive changes.
Sample Data Diff
Beyond schema changes, Slimmer CI can sample rows from affected models to show actual data differences:
- Row count delta (how many rows gained or lost)
- Statistical summary (mean, p50, p99 for numeric columns)
- Top-N most impacted rows
- Side-by-side comparison of sample values
AI-Powered Code Review
Every Slimmer CI run automatically generates an AI review comment on your pull request:
- Grounded in your diff: The review analyzes only the models that changed and their downstream impact
- Sticky PR comment: A single, auto-updating comment summarizes findings (no duplicate comments on re-pushes)
- Actionable feedback: Highlights potential issues like missing tests, breaking schema changes, or performance concerns
- Multi-provider support: AI review comments post to GitHub, GitLab, Azure DevOps, and Bitbucket
- Enabled by default: Works out of the box with no configuration. Can be disabled per environment if needed
The AI review acts as an always-on first reviewer, catching common issues before a human reviewer looks at the PR.
Actionable Failure Reports
When a run fails, you do not have to scroll through raw logs to find out why. Slimmer CI builds an actionable failure report on the run detail:
- Per-node results: exactly which models or tests failed, their resource type, and the error message for each one
- Log tail: the last lines of the dbt log, color-coded so errors and warnings stand out, giving you immediate context without opening the full output
- Honest messaging: if logs are not available for a run, the report says so plainly instead of showing a confusing empty state
- Open the real source file: click a failed node to jump to its actual source file in the editor. For a failed test, that means the model or the schema YAML the test is defined on, not a generated file, so you land exactly where the fix belongs
From a failed model you can hand off straight to Atlas: dbdeux opens the model file and starts a grounded fix request, so you go from a red check to a proposed fix in a couple of clicks.
Commit Status Gate
Slimmer CI posts a commit status to your Git provider. Configure it as a required check to prevent merging PRs with failing models or tests.
PR Digest Comment
In addition to commit statuses, Slimmer CI posts a rich digest comment directly on your pull request:
- Schema diff summary (columns added, removed, type changes)
- Sample data comparison
- Build and test outcomes
- Exposure/downstream impact summary
- AI review pointer (link to the full AI analysis)
- Links back to the full run details in dbdeux
The digest is a sticky comment that updates in place on each push, so there is no comment clutter. Links in the comment deep-link straight to the exact run in dbdeux, so a reviewer goes from the PR to the detailed results in one click.
Each PR run detail in dbdeux shows a clickable commit SHA that links directly to the commit on your Git provider, making it easy to cross-reference the CI result with the exact code version.
Managing Your Run History
As a project accumulates CI runs, the run list stays easy to work with:
- Pull request first: runs are grouped by pull request so you see the current state of each PR, not a flat wall of individual builds
- Filters: narrow the list by status (success, failed, running), pull request number, or a date range
- Load more: results paginate instead of loading everything at once, so the list stays fast on busy projects
- Hidden runs: archive noisy or one-off runs to keep the list focused. Hidden runs are filtered out server-side by default and can be shown again with a single toggle whenever you need them
- Deep links stay resolvable: a run you open from a PR comment or a shared link always stays selected, even if it falls outside the current filter or page
Organization owners and admins can also manage which connections a project's CI can use, so production access stays controlled.
Exposure Impact Analysis
Slimmer CI identifies exposures (dashboards, reports, ML features) that sit downstream of your changed models. The PR run detail shows:
- Which exposures are affected by the current change
- The full downstream dependency chain
- A dedicated panel for reviewing exposure impact before merging
Storage Footprint
The PR probe card shows warehouse storage impact:
- Base size: storage before your changes
- Head size: storage after your changes
- Delta: net increase or decrease
This helps catch unintended table growth before it reaches production.
PR Run Overview Tab
The PR run detail page includes an at-a-glance Overview tab summarizing:
- Build status for each model
- Schema diff highlights
- Storage delta
- Exposure impact count
- Direct link to the AI review comment
Every run also states the exact context it ran in, so a result is never ambiguous: the environment, the warehouse it built against, and the user whose credentials the build ran with. The run list is branch-aware and shows a Compares against indicator, so you can see at a glance which deployment each pull request was validated against. When no environment matches a pull request's base branch, dbdeux skips the run with a clear explanation instead of failing with a confusing error, so a missing mapping never looks like a broken build.
Breaking Change Detection
Slimmer CI automatically classifies schema changes by severity so reviewers can focus on what matters:
| Change kind | Severity | What it catches |
|---|---|---|
| Column removed | Breaking | A column that downstream consumers depend on has been dropped |
| Column renamed | Breaking | A column name changed, which breaks any downstream SELECT or ref |
| Type changed | Breaking | A column's data type changed in a way that may break casts or joins |
| Materialization changed | Breaking | A model switched from view to table (or vice versa), affecting query plans |
| Node removed | Breaking | An entire model was deleted from the project |
| Column added | Additive | A new column appeared (safe for existing consumers) |
Breaking changes are highlighted with a red badge in the PR Overview tab and in the digest comment. Additive changes are marked green.
Contract and Access Awareness
Slimmer CI reads your models' dbt governance metadata so severity reflects real risk, not just raw column diffs:
- Contracted models carry an explicit promise about their columns and types, so a change to one is called out as higher risk than the same change on an uncontracted model
- Public models are meant for other teams to reference, so changes to them are flagged as more impactful than changes to
privateorprotectedmodels - Versioned and deprecated models are labeled in the diff, so reviewers know when they are looking at an outdated or sunsetting model
This context appears alongside the change list, giving reviewers the full picture of who a change affects before they approve.
Logic Change Detection
When a model's compiled SQL changes but its schema stays the same (same columns, same types), Slimmer CI detects it as a logic change. This catches cases where the output shape is unchanged but the data itself may differ - for example, changing a WHERE clause or a JOIN condition.
Logic changes are surfaced with an info badge in the PR overview and digest comment, giving reviewers visibility into behavioral changes that a pure schema diff would miss.
Merge Impact and Revert PR
When a PR with breaking schema changes is merged, Slimmer CI sends a downstream impact alert to data engineers, listing which models, exposures, and dashboards are affected.
If a merged PR causes issues, the PR run detail page includes a Revert PR button:
- Click Revert PR on any merged PR run
- Slimmer CI creates a new branch that restores all changed files to their pre-merge state
- A revert PR is opened against the base branch, running through the same CI gate
- Merge the revert PR to undo the changes
The revert flow works across all four Git providers (GitHub, GitLab, Azure DevOps, Bitbucket). It is available only for merged PR runs and only when the original branch and commit are still resolvable.
The merge impact toggle is configurable per project in Project Settings > Slimmer CI.
Metric Gate
When Atlas Metrics is enabled, Slimmer CI automatically compares the metric catalog on the base branch against the head branch. Any breaking metric change (removed metric, modified expression, dropped dimension) blocks the PR. This ensures governed metric definitions cannot change without explicit review.
The metric gate results appear in the PR Overview tab and in the digest comment alongside schema and exposure impact.
Resource Type Selector
Choose which dbt resource types Slimmer CI validates per project:
- Models
- Tests
- Seeds
- Snapshots
This gives teams fine-grained control over what runs during CI.
Supported Git Providers
Slimmer CI works with all supported Git providers:
| Provider | PR detection | Commit status | Auto-provisioning |
|---|---|---|---|
| GitHub | Webhook on PR open/sync | Check run | Automatic |
| GitLab | MR webhook | Commit status API | Automatic |
| Azure DevOps | Service hook on PR | Status API | Automatic |
| Bitbucket Cloud | PR webhook | Commit status API | Automatic |
Webhooks are auto-provisioned when you connect your repository. No manual configuration needed.
Webhook Repair
If a webhook is accidentally deleted from your Git provider, you can re-provision it without recreating the project:
- Go to Project Settings → Slimmer CI
- Click Repair Webhook
- The webhook is re-created with the correct configuration
Performance
Slimmer CI is optimized for speed:
- Fast start: CI environments spin up in under 3 seconds
- Smart caching: Skips re-runs when the same commit has already been validated
- Coalesced runs: Rapid pushes are merged so only the latest commit is built
- Auto-recovery: Stalled or stuck runs are detected and restarted automatically
- Pinned dbt version per project ensures consistent builds across all CI runs
- 4-8x faster than traditional full-project CI
Guided Setup and Readiness
Slimmer CI compares each pull request against the last known state of the branch it deploys to, so it needs a production environment and a state baseline to be at its fastest. Instead of failing silently when something is missing, the Slimmer CI page walks you through the exact steps in order and tells you what to do next:
- No production environment: a prompt to create one, since the production environment defines the deployment target whose branch the state baseline represents
- Production branch missing on the repo: the exact environment, branch, and repository are named so you know precisely what to fix
- No state baseline yet: a one-click Generate production state action with live progress. Pull requests still run while this is building; they simply run a full build until the baseline exists, so a missing baseline never blocks or fails CI
- Ready: a compact summary confirms exactly what pull requests now compare against
While the production state is being generated, the page shows live build progress and a running indicator, and re-running gives honest feedback about what is happening rather than a silent spinner.
Transparent Baselines
When there is no baseline to compare against, Slimmer CI does not guess or skip. It runs a full build and tells you plainly that it did so because no baseline was available yet. Once the baseline exists, runs automatically switch back to building only what changed. You always know whether a run was slim or full and why.
Per-Environment CI Settings
Slimmer CI can be tuned per deployment environment, not just per project:
- Enable or disable per environment: a pull request whose base branch deploys to a given environment can turn CI on or off for that environment, or leave it to inherit the project-level setting
- Choose what to compare against: an explicit CI environment selector lets an environment compare its pull requests against a different deployment environment. For example, a hotfix environment can validate against staging or production rather than its own branch. The setting is explicit rather than implied, so there is no guessing about which state a run built against
These settings live on the environment and fall back to the project defaults when left unset, so most teams never need to touch them while advanced workflows stay possible.
Setup
- Navigate to Project Settings
- Enable the Slimmer CI Runner toggle
- Slimmer CI begins running on the next pull request
No additional infrastructure, tokens, or external CI systems required. Everything runs within the dbdeux platform.
Per-Project Settings
Fine-tune CI behavior for each project in Project Settings > Slimmer CI:
| Setting | What it controls |
|---|---|
| CI Runner enabled | Master toggle - turns CI on/off for the project |
| Resource types | Which dbt resource types CI validates (models, tests, seeds, snapshots). Null means all types |
| dbt version | Pin a specific dbt engine version for CI runs. Null uses the managed default (Core 1.8) |
| Merge impact enabled | Toggle post-merge downstream impact alerts on/off per project |
These settings let teams customize CI behavior per project without affecting other projects in the organization.
How It Compares
| Capability | Slimmer CI | dbt Cloud CI | GitHub Actions + dbt |
|---|---|---|---|
| Setup | One toggle, zero config | Requires job configuration and webhook setup | YAML pipeline authoring, runner provisioning |
| Build scope | Only modified models + downstream (state:modified+) | Full project or manual selector | Manual selector or custom scripting |
| Cold start | Under 3 seconds | Minutes (container provisioning) | Varies by runner pool |
| Schema diff | Automatic column-level diff posted on every PR | Not available | Requires custom tooling |
| AI code review | Automatic AI review comment on every PR | Not available | Requires separate AI integration |
| Metric gate | Breaking metric changes block the PR automatically | Not available | Not available |
| Exposure impact | Shows affected dashboards and downstream consumers | Not available | Not available |
| dbt vars injection | Inherits per-environment --vars automatically | Manual configuration | Manual CLI flags |
| Breaking change detection | Automatic severity classification (removals, renames, type changes) | Not available | Not available |
| Logic change detection | Detects compiled-SQL logic changes even when schema is unchanged | Not available | Not available |
| Revert PR | One-click revert PR from any merged run across all Git providers | Manual revert workflow | Manual revert workflow |
| Cost | Included in platform, no extra compute billing | Separate CI compute costs | Runner compute costs |