jradtilbrook
commented
7 months ago Thanks for raising this. I'm reading the docs on this lifecycle and getting a different conclusion on its use; that if the linked resource changes, it will trigger a destroy/create on the parent resource.
So I believe this is working correctly. Ie. if terraform_data.buildkite_key_version.input changes, it will trigger terraform to plan a destroy of the pipeline and recreate it.
But that is out of the provider hands and is at the terraform level.
The pipeline resource doesn't define any attributes that will require a replacement to be created (through a destroy-then-create). This is done at the schema level, eg: https://github.com/hashicorp/terraform-provider-aws/blob/dbccf03ad2ecf74ac54987302ad3384a77481883/internal/service/auditmanager/organization_admin_account_registration.go#L46.
So changing any attributes on a pipeline resource will afford an update-in-place. So its the use of this lifecycle that has caused the delete and recreate in this case.
I think it might be helpful to understand more of the use-case you have to help you in the right direction. Terraform (and our provider) should be handling the updating of resources in place when it detects a diff. It doesn't provide a mechanism to force an update (only a recreate). Now, there could be a bug in our provider that is not correctly producing a diff and that might be the problem here. If you can let us know more of the usecase, that will help identify what it might be and a fix
Adding the following to trigger a pipeline update in-place:
resource "buildkite_pipeline" "pipeline" { lifecycle { replace_triggered_by = [ terraform_data.buildkite_key_version.input ] }
Had the unexpected effect of a destroy/create of the pipeline, which is undesirable in our system.
It would be better if the provider can prefer update in-place to destroy/create. If this is not possible, then we'd like to have documentation on exactly what triggers destroy/create so we can plan workarounds.