#spacelift (2023-05)
2023-05-01
In an effort to automate in-repo Spacelift stacks, I hope to run the spacelift module after terraform adds the new repo to the Spacelift’s Github App installation of allowed repos. When setting module.spacelift to depend_on the github_app_installation_repositories resource, I’m getting an error that seems to originate within the CloudPosse Spacelift Module (in :thread: ).
Any suggestions on only executing cloudposse/cloud-infrastructure-automation/spacelift after another resource completes?
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.
@Jeremy White (Cloud Posse) has joined the channel
2023-05-02
2023-05-03
What is a Kubernetes Operator? Definition & Examples Learn what Kubernetes operator is, the situations where they’re useful, and where to go to get started building your own.
2023-05-04
12 Most Useful Container Orchestration Tools in 2023 Orchestration is key to modern DevOps workflows - see the list of the most helpful container orchestration tools.
2023-05-05
Join Spacelift at AWS Summit Stockholm 2023 Are you ready for AWS Summit Stockholm? Let’s meet there! Our engineers will be at booth S11 with our Spacelift swag, so do visit.
