#spacelift (2023-05)

Cursory looks seems to do with passing toset() to for_each:

module.spacelift.spacelift_policy_attachment.push_administrative[0]: Refreshing state... [id=global-administrative-push-policy/ID]
module.spacelift.spacelift_policy_attachment.trigger_administrative[0]: Refreshing state... [id=global-administrative-trigger-policy/ID]
╷
│ Error: Invalid for_each argument
│ 
│   on .terraform/modules/spacelift/main.tf line 82, in resource "spacelift_policy" "custom":
│   82:   for_each = toset(local.distinct_policy_names)
│     ├────────────────
│     │ local.distinct_policy_names is a list of string, known only after apply
│ 
│ The "for_each" set includes values derived from resource attributes that
│ cannot be determined until apply, and so Terraform cannot determine the
│ full set of keys that will identify the instances of this resource.
│ 
│ When working with unknown values in for_each, it's better to use a map
│ value where the keys are defined statically in your configuration and where
│ only the values contain apply-time results.
│ 
│ Alternatively, you could use the -target planning option to first apply
│ only the resources that the for_each value depends on, and then apply a
│ second time to fully converge.
╵
[RunID] Unexpected exit code when planning changes: 1

We have a pretty opinionated implementation of Spacelift. It’s designed predominantly to work with atmos

@Tyler Rankin are you planning on using atmos?

Yes, in fact we do use Atmos as well. My hope was to add the Github resource to our module which would ensure the in-repo terraform repository has been added to the Spacelift Github App allow list. Otherwise, the stack could fail if the Github App can’t access the repo when module.spacelift actually provisions the new stack.

Aha, cool!

So I believe the depend_on stuff was recently worked on by @Jeremy White (Cloud Posse)

@Andriy Knysh (Cloud Posse) also let me know that there may be changes coming to the Spacelift module. I hope those changes aren’t too far out and might add support for using depends_on with it

Transferring this to a private channel.

I think it’s a great idea

dang, we missed https://sweetops.slack.com/archives/C059RSPA22W/p1685539845134769 where they went purely ChatGPT

Could you provide an example?

An example of a terraform stack with alias providers?

provider "aws" {
  alias  = "prod_use1"
  region = "us-east-1"
}
provider "aws" {
  alias  = "prod_euw1"
  region = "eu-west-1"
}

I was mainly asking if people here are generally just using Spacelift’s provided drift detection or other tools like driftctl? I was personally really interested in driftctl, but it has these restrictions. https://docs.driftctl.com/0.34.0/limitations/#aws-regions--credentials-limits like not being able to work with stacks that have alias providers.

Aha, yes, makes sense. We’re aware of Driftctl, but for the aforementioned reasons haven’t really invested in it. The scheduled plans (aka drift detection) in Spacelift offer 80% of the benefits with 20% of the effort, so to say. Of course it doesn’t tell you what’s not under IaC, but it does catch everything that’s in IaC but no longer reconciling with what’s deployed.

Thanks, I appreciate the info!