dbt-labs / terraform-provider-dbtcloud

dbt Cloud Terraform Provider
https://registry.terraform.io/providers/dbt-labs/dbtcloud
MIT License
80 stars 18 forks source link

docs: example - how to fail during apply when a service token is used… #244

Closed matthiasng closed 2 months ago

matthiasng commented 3 months ago

While migrating our dbt resoruces to terraform i encounter the gitlab integration issue #192 where you cant create a working repository in dbt with a service token. A big problem for me is that we will use the module I'm writing to create new dbt environments/jobs/projects in the future, but the apply stage doesn't throw an error when a service token is used.

So here is a small example of how to throw an error during the apply phase when a service token is used to create a Gitlab repository.

b-per commented 3 months ago

Thanks for that! I will get the docs updated in the next release with those examples.

Not being ultra familiar with null_resource, is it fair to say that for Terraform 1.4+ we could also use the new terraform_data resource?

resource "terraform_data" "check_repository" {
  lifecycle {
    precondition {
      condition     = dbtcloud_repository.gitlab_repo.repository_credentials_id != 0
      error_message = "Repositories created with a service token are currently not working properly (https://github.com/dbt-labs/terraform-provider-dbtcloud/issues/192)"
    }
  }
}
matthiasng commented 3 months ago

I just tested it and terraform_data seems to work similar to null_resource in this case.

b-per commented 3 months ago

I am thinking a bit more about it and I actually could/should add this check in the provider code itself. If repository_credentials_id = 0 then raise an error message that it might be due to using a service token.

matthiasng commented 3 months ago

That would be even better. If you run the check right after creating the repository, you could also try to remove it so that no broken repository is left behind (which is the case with my workaround)

b-per commented 2 months ago

Handled in the logic in #246