Description
When importing an existing buildkite_pipeline that has a provider_settings block in its Terraform configuration, terraform plan shows the full provider_settings object as needing to be created, even when the config matches the actual pipeline. Additionally, if even a single provider_settings attribute differs, all unspecified string attributes show spurious diffs like null -> (known after apply).
To Reproduce
- Create a pipeline in Buildkite (or use an existing one)
- Write a Terraform config for it with a
provider_settings block:
resource "buildkite_pipeline" "example" {
name = "my-pipeline"
repository = "https://github.com/org/repo.git"
provider_settings {
build_branches = true
build_pull_requests = false
}
}
- Run
terraform import buildkite_pipeline.example <pipeline-id>
- Run
terraform plan
- The plan shows the entire
provider_settings block as a new addition, plus fields like:
~ filter_condition = null -> (known after apply)
~ pull_request_branch_filter_configuration = null -> (known after apply)
~ trigger_mode = null -> (known after apply)
Expected behavior
After importing, terraform plan should show no changes if the config matches the pipeline, and only the actually-differing attributes if the config differs.
Description
When importing an existing
buildkite_pipelinethat has aprovider_settingsblock in its Terraform configuration,terraform planshows the fullprovider_settingsobject as needing to be created, even when the config matches the actual pipeline. Additionally, if even a singleprovider_settingsattribute differs, all unspecified string attributes show spurious diffs likenull -> (known after apply).To Reproduce
provider_settingsblock:terraform import buildkite_pipeline.example <pipeline-id>terraform planprovider_settingsblock as a new addition, plus fields like:Expected behavior
After importing,
terraform planshould show no changes if the config matches the pipeline, and only the actually-differing attributes if the config differs.