dbt CI
Etleap runs preview builds as part of your dbt code development process via automated checks on your GitHub pull requests (PRs). This page describes the benefits of having continuous integration (CI) in your dbt development workflow and how it works with Etleap.
Overview
Etleap can trigger preview builds automatically for GitHub PRs so you can validate your changes prior to merging them into the main branch.
A preview build builds all dbt models, executes all tests, and reports the build status on the PR as a GitHub commit check status. Additionally, the preview builds produce build logs and user-inspectable tables in a staging schema.
Having GitHub PR checks for your dbt project can be beneficial in the following ways:
- Increasing confidence and adding assurances that project changes will work as expected in production.
- Reducing the time to push code changes to production, through build and test automation.
If you have designated a default selector , the preview build will only build models and execute tests that meet the criteria of the default selector.
How GitHub PR Checks Work
The build triggers either when a new pull request (PR) is opened (in which case the latest commit of the PR will be built) or when the new commit is added to an open PR.
Tracking the check status
When Etleap picks up the commit, the commit check status will be reported in your GitHub UI.

Once the build is complete, the commit check status will report whether the build succeeded or failed. By clicking on Details in your repo you will be redirected to the Etleap page that shows the dbt build log and more information about the build.

You can setup your GitHub repo to only allow PRs with successful checks to be merged.
Temporary schemas
All of the dbt preview builds are built in a temporary schema with the format etleap_dbt_pr_<pr_id>_<etleap_random_identifier>
, where pr_id
is the unique identifier of the PR in the GitHub repository.
Once the pull request is closed, the temporary schemas (all etleap_dbt_pr_<pr_id>_<etleap_random_identifier>%
schemas) are deleted.
Limitations
- If your project specifies custom schemas using the
generate_schema_name
macro and the generated schemas do not matchetleap_dbt_pr_<pr_id>_<etleap_random_identifier>%
pattern, they will not be dropped after the PR is closed. - Only one commit will ever be built at the same time for a single pull request. If the PR has multiple commits which were not yet built, the latest one will be picked up, while the older ones will be skipped.