Release v1.8.0 · cloudposse/terraform-spacelift-cloud-infrastructure-automation

feat(spacelift-stack): replace administrative flag with spacelift_role_attachment Xeboc (#200)

## what

Removes administrative = var.administrative from the spacelift_stack resource — the Spacelift API removed this field on June 1, 2026; any stack with it set now fails on apply
Adds data "spacelift_role" "admin" to resolve the space-admin built-in role ID by slug
Adds spacelift_role_attachment.admin conditioned on var.administrative == true, granting Space Admin on the stack's own space — equivalent behavior to the removed flag
Bumps Spacelift provider minimum from >= 0.1.31 to >= 1.37.0 (required for spacelift_role_attachment with stack_id)
var.administrative is retained — callers passing true get a role attachment, callers passing false are unaffected
Pins cloudposse/utils to < 1.32.0 in modules/spacelift-stacks-from-atmos-config and the corresponding example — v1.32+ embeds Atmos v1.207+ which changed empty base_path resolution from CWD to git root, breaking the terratest setup where the example runs in a subdirectory

why

Spacelift removed the administrative flag from the spacelift_stack API on June 1, 2026. Every stack using this module with administrative = true is currently broken with: could not update stack: the administrative flag is no longer supported on stacks; attach the Space admin role to the stack instead
Spacelift automatically backfilled spacelift_role_attachment (Space Admin) on previously-administrative stacks on June 1. Existing users must import those backfilled resources before applying to avoid a conflict error. Import ID format: STACK/<ROLE_BINDING_ULID>. IDs retrievable via GraphQL: { stack(id: "<stack-id>") { roleBindings { id } } }
The cloudposse/utils pin fixes a pre-existing test regression introduced when utils v1.32.0 shipped — unrelated to the administrative flag changes but blocking CI on this PR