dbt Cloud enterprise customers have the added benefit of bringing their own GitLab OAuth application to dbt Cloud. This tier benefits from extra security, as dbt Cloud will:
Enforce user authorization with OAuth.
Carry GitLab's user repository permissions (read / write access) through to dbt Cloud or dbt Cloud CLI's git actions.
In order to connect GitLab in dbt Cloud, a GitLab account admin must:
The application form in GitLab should look as follows when completed:
GitLab group owned application form
Click Save application in GitLab, and GitLab will then generate an Application ID and Secret. These values will be available even if you close the app screen, so this is not the only chance you have to save them.
If you're a Business Critical customer using IP restrictions, ensure you've added the appropriate Gitlab CIDRs to your IP restriction rules, or else the Gitlab connection will fail.
After you've created your GitLab application, you need to provide dbt Cloud information about the app. In dbt Cloud, account admins should navigate to Account Settings, click on the Integrations tab, and expand the GitLab section.
Note, if you have a special hosted version of GitLab, modify the GitLab Instance to use the hostname provided for your organization instead - for example https://gitlab.yourgreatcompany.com/.
Once the form is complete in dbt Cloud, click Save.
You will then be redirected to GitLab and prompted to sign into your account. GitLab will ask for your explicit authorization:
GitLab Authorization Screen
Once you've accepted, you should be redirected back to dbt Cloud, and your integration is ready for developers on your team to personally authenticate with.
dbt Cloud developers on the Enterprise plan must each connect their GitLab profiles to dbt Cloud, as every developer's read / write access for the dbt repo is checked in the dbt Cloud IDE or dbt Cloud CLI.
To connect a personal GitLab account:
From dbt Cloud, click on your account name in the left side menu and select Account settings.
Select Personal profile under the Your profile section.
Scroll down to Linked accounts.
If your GitLab account is not connected, you’ll see "No connected account". Select Link to begin the setup process. You’ll be redirected to GitLab, and asked to authorize dbt Cloud in a grant screen.
Authorizing the dbt Cloud app for developers
Once you approve authorization, you will be redirected to dbt Cloud, and you should see your connected account. You're now ready to start developing in the dbt Cloud IDE or dbt Cloud CLI.
When you connect dbt Cloud to a GitLab repository, GitLab automatically registers a webhook in the background, viewable under the repository settings. This webhook is also used to trigger CI jobs when you push to the repository.
If you're unable to trigger a CI job, this usually indicates that the webhook registration is missing or incorrect.
To resolve this issue, navigate to the repository settings in GitLab and view the webhook registrations by navigating to GitLab --> Settings --> Webhooks.
Some things to check:
The webhook registration is enabled in GitLab.
The webhook registration is configured with the correct URL and secret.
If you're still experiencing this issue, reach out to the Support team at support@getdbt.com and we'll be happy to help!
Errors importing a repository on dbt Cloud project set up
If you don't see your repository listed, double-check that:
Your repository is in a Gitlab group you have access to. dbt Cloud will not read repos associated with a user.
If you do see your repository listed, but are unable to import the repository successfully, double-check that:
You are a maintainer of that repository. Only users with maintainer permissions can set up repository connections.
If you imported a repository using the dbt Cloud native integration with GitLab, you should be able to see if the clone strategy is using a deploy_token. If it's relying on an SSH key, this means the repository was not set up using the native GitLab integration, but rather using the generic git clone option. The repository must be reconnected in order to get the benefits described above.
How can I fix my .gitignore file?
A .gitignore file specifies which files git should intentionally ignore or 'untrack'. dbt Cloud indicates untracked files in the project file explorer pane by putting the file or folder name in italics.
If you encounter issues like problems reverting changes, checking out or creating a new branch, or not being prompted to open a pull request after a commit in the dbt Cloud IDE — this usually indicates a problem with the .gitignore file. The file may be missing or lacks the required entries for dbt Cloud to work correctly.
The following sections describe how to fix the .gitignore file in:
Fix in the dbt Cloud IDE
To resolve issues with your gitignore file, adding the correct entries won't automatically remove (or 'untrack') files or folders that have already been tracked by git. The updated gitignore will only prevent new files or folders from being tracked. So you'll need to first fix the gitignore file, then perform some additional git operations to untrack any incorrect files or folders.
Launch the Cloud IDE into the project that is being fixed, by selecting Develop on the menu bar.
In your File Explorer, check to see if a .gitignore file exists at the root of your dbt project folder. If it doesn't exist, create a new file.
Open the new or existing gitignore file, and add the following:
# ✅ Correct target/ dbt_packages/ logs/ # legacy -- renamed to dbt_packages in dbt v1 dbt_modules/
Note — You can place these lines anywhere in the file, as long as they're on separate lines. The lines shown are wildcards that will include all nested files and folders. Avoid adding a trailing '*' to the lines, such as target/*.
For more info on gitignore syntax, refer to the Git docs.
Save the changes but don't commit.
Restart the IDE by clicking on the three dots next to the IDE Status button on the lower right corner of the IDE screen and select Restart IDE.
Restart the IDE by clicking the three dots on the lower right or click on the Status bar
Once the IDE restarts, go to the File Explorer to delete the following files or folders (if they exist). No data will be lost:
target, dbt_modules, dbt_packages, logs
Save and then Commit and sync the changes.
Restart the IDE again using the same procedure as step 5.
Once the IDE restarts, use the Create a pull request (PR) button under the Version Control menu to start the process of integrating the changes.
When the git provider's website opens to a page with the new PR, follow the necessary steps to complete and merge the PR into the main branch of that repository.
Note — The 'main' branch might also be called 'master', 'dev', 'qa', 'prod', or something else depending on the organizational naming conventions. The goal is to merge these changes into the root branch that all other development branches are created from.
Return to the dbt Cloud IDE and use the Change Branch button, to switch to the main branch of the project.
Once the branch has changed, click the Pull from remote button to pull in all the changes.
Verify the changes by making sure the files/folders in the .gitignore file are in italics.
A dbt project on the main branch that has properly configured gitignore folders (highlighted in italics).
Fix in the git provider
Sometimes it's necessary to use the git providers web interface to fix a broken .gitignore file. Although the specific steps may vary across providers, the general process remains the same.
There are two options for this approach: editing the main branch directly if allowed, or creating a pull request to implement the changes if required:
Edit in main branch
Unable to edit main branch
When permissions allow it, it's possible to edit the .gitignore directly on the main branch of your repo. Here are the following steps:
Go to your repository's web interface.
Switch to the main branch and the root directory of your dbt project.
Find the .gitignore file. Create a blank one if it doesn't exist.
Edit the file in the web interface, adding the following entries:
target/ dbt_packages/ logs/ # legacy -- renamed to dbt_packages in dbt v1 dbt_modules/
Commit (save) the file.
Delete the following folders from the dbt project root, if they exist. No data or code will be lost:
target, dbt_modules, dbt_packages, logs
Commit (save) the deletions to the main branch.
Switch to the dbt Cloud IDE, and open the project that you're fixing.
Rollback your repo to remote in the IDE by clicking on the three dots next to the IDE Status button on the lower right corner of the IDE screen, then select Rollback to remote.
Note — Rollback to remote resets your repo back to an earlier clone from your remote. Any saved but uncommitted changes will be lost, so make sure you copy any modified code that you want to keep in a temporary location outside of dbt Cloud.
Once you rollback to remote, open the .gitignore file in the branch you're working in. If the new changes aren't included, you'll need to merge the latest commits from the main branch into your working branch.
Go to the File Explorer to verify the .gitignore file contains the correct entries and make sure the untracked files/folders in the .gitignore file are in italics.
Great job 🎉! You've configured the .gitignore correctly and can continue with your development!
If you can't edit the .gitignore directly on the main branch of your repo, follow these steps:
Go to your repository's web interface.
Switch to an existing development branch, or create a new branch just for these changes (This is often faster and cleaner).
Find the .gitignore file. Create a blank one if it doesn't exist.
Edit the file in the web interface, adding the following entries:
target/ dbt_packages/ logs/ # legacy -- renamed to dbt_packages in dbt v1 dbt_modules/
Commit (save) the file.
Delete the following folders from the dbt project root, if they exist. No data or code will be lost:
target, dbt_modules, dbt_packages, logs
Commit (save) the deleted folders.
Open a merge request using the git provider web interface. The merge request should attempt to merge the changes into the 'main' branch that all development branches are created from.
Follow the necessary procedures to get the branch approved and merged into the 'main' branch. You can delete the branch after the merge is complete.
Once the merge is complete, go back to the dbt Cloud IDE, and open the project that you're fixing.
Rollback your repo to remote in the IDE by clicking on the three dots next to the IDE Status button on the lower right corner of the IDE screen, then select Rollback to remote.
Note — Rollback to remote resets your repo back to an earlier clone from your remote. Any saved but uncommitted changes will be lost, so make sure you copy any modified code that you want to keep in a temporary location outside of dbt Cloud.
Once you rollback to remote, open the .gitignore file in the branch you're working in. If the new changes aren't included, you'll need to merge the latest commits from the main branch into your working branch.
Go to the File Explorer to verify the .gitignore file contains the correct entries and make sure the untracked files/folders in the .gitignore file are in italics.
Great job 🎉! You've configured the .gitignore correctly and can continue with your development!
For more info, refer to this detailed video for additional guidance.
I'm seeing a Gitlab authentication out of date error loop
If you're seeing a 'GitLab Authentication is out of date' 500 server error page - this usually occurs when the deploy key in the repository settings in both dbt Cloud and GitLab do not match.
No worries - this is a current issue the dbt Labs team is working on and we have a few workarounds for you to try:
Under Repository Settings, manually add to your Gitlab project deploy key repo (with Grant write permissions box checked).
Go back to dbt Cloud, refresh your page and try developing again.
If you've tried the workarounds above and are still experiencing this behavior - reach out to the Support team at support@getdbt.com and we'll be happy to help!
Can self-hosted GitLab instances only be connected via dbt Cloud Enterprise plans?
Presently yes, this is only available to Enterprise users. This is because of the way you have to set up the GitLab app redirect URL for auth, which can only be customized if you're a user on an Enterprise plan.
Check out our pricing page for more information or feel free to contact us to build your Enterprise pricing.
How to migrate git providers
To migrate from one git provider to another, refer to the following steps to avoid minimal disruption:
Outside of dbt Cloud, you'll need to import your existing repository into your new provider.
As an example, if you're migrating from GitHub to Azure DevOps, you'll need to import your existing repository (GitHub) into your new git provider (Azure DevOps). For detailed steps on how to do this, refer to your git provider's documentation (Such as GitHub, GitLab, Azure DevOps)
Disconnect the old repository in dbt Cloud by going to Account Settings and then Projects. Click on the Repository link, then click Edit and Disconnect.
Disconnect and reconnect your git repository in your dbt Cloud Account Settings pages.
On the same page, connect to the new git provider repository by clicking Configure Repository
If you're using the native integration, you may need to OAuth to it.
That's it, you should now be connected to the new git provider! 🎉
Note — As a tip, we recommend you refresh your page and dbt Cloud IDE before performing any actions.