Please add support for resolving a worker pool’s ID by name in the data "spacelift_worker_pool" data source, to enable assigning worker_pool_id to resources without introducing plan noise.
I’m not sure how your stacks are deployed today, but for our use case, we have an admin stack that deploys all of our stacks via Terraform Modules. I do what you are asking for in a more convoluted manner due to the way the data source works today.
locals {
worker_pool_ids = {
for pool in data.spacelift_worker_pools.private.worker_pools : pool.name => pool.worker_pool_id
}
}
I use other variables and conditional expressions to fetch the id of the necessary worker pool by name then from the local map that was established like local.worker_pool_ids[“Worker Pool Name Here”]. In my case, I fetch them once and pass to my module as a variable, so it’s actually var.worker_pool_ids and that locals is done in my project_root and passed to the module call.
My plans always come out assigned id for the worker pool rather than (computed). Maybe that’s something you could look at utilizing until/if this is implemented?
Teal Savanna
•
Jul 2, 2025
Additional context:
✅ Desired Outcome Allow users to write:
data "spacelift_worker_pool""default" {
name = "default"
}
resource "spacelift_stack""example" {
name = "stack-example"
worker_pool_id = data.spacelift_worker_pool.default.id
}
Where: The name field identifies the worker pool.
The id is resolved during the plan phase.
No Computed values are involved in the returned id - ensuring no false-positive diffs when assigning it to a spacelift_stack.
🚫 Current Workaround (With Drawbacks)
Right now, users must use the plural data source: However, this causes persistent plan diffs, because:
The values inside worker_pools are marked as Computed.
Terraform cannot resolve them at plan time and marks worker_pool_id = (known after apply).
This results in noisy plans on every run, even when no actual changes exist.
Log in to comment and vote
Comments2
Turquoise Deer
Jul 18, 2025
Agree this would be simpler!
I’m not sure how your stacks are deployed today, but for our use case, we have an admin stack that deploys all of our stacks via Terraform Modules. I do what you are asking for in a more convoluted manner due to the way the data source works today.
locals { worker_pool_ids = { for pool in data.spacelift_worker_pools.private.worker_pools : pool.name => pool.worker_pool_id } }I use other variables and conditional expressions to fetch the id of the necessary worker pool by name then from the local map that was established like local.worker_pool_ids[“Worker Pool Name Here”]. In my case, I fetch them once and pass to my module as a variable, so it’s actually var.worker_pool_ids and that locals is done in my project_root and passed to the module call.
My plans always come out assigned id for the worker pool rather than (computed). Maybe that’s something you could look at utilizing until/if this is implemented?
Teal Savanna
Jul 2, 2025
Additional context:
✅ Desired Outcome Allow users to write:
data "spacelift_worker_pool" "default" { name = "default" }resource "spacelift_stack" "example" { name = "stack-example" worker_pool_id = data.spacelift_worker_pool.default.id }Where:
The name field identifies the worker pool.
The id is resolved during the plan phase.
No Computed values are involved in the returned id
- ensuring no false-positive diffs when assigning it to a spacelift_stack.
🚫 Current Workaround (With Drawbacks)
Right now, users must use the plural data source: However, this causes persistent plan diffs, because:
The values inside worker_pools are marked as Computed.
Terraform cannot resolve them at plan time and marks worker_pool_id = (known after apply).
This results in noisy plans on every run, even when no actual changes exist.