#spacelift (2024-10)

Yes, but you need to use our components for it. We use a terraform module that reads the stack configurations to provision the spacelift stacks.

https://docs.cloudposse.com/layers/spacelift/

I wish it was as easy as modifying the workflow file, but there’s more to it than that.

Also, because we have an import and inheritance model, spacelift won’t work well by itself because policies are insufficient to determine what is affected. Therefore we recommend using our spacelift GitHub action which works around this spacelift limitation.

Sure, I’m using this one. I’ve provisioned stacks for spaces and admin-stack components with no issues. Now, I’m trying to trigger a stack until I get “No changes” as both of these stacks are freshly provisioned. In general, what I’m trying to achieve is using Atmos instead of Terraform as a workflow tool in Spacelift. For Terraform, it seems to require switching to directory with component I want to deploy first, so using before_init hook to cd "${TF_VAR_spacelift_workspace_root}/source/${TF_VAR_spacelift_project_root}" first. At least that’s my understanding. Then, it can select the workspace = ok. After that, I don’t have any backend.json and *.tfvars file there, too, as Atmos creates them on the fly. terraform plan uses local backend in such case I guess. So, I’d have to include them in the repo as well. Using Atmos would allow me to mimic the process I’m using locally, i.e. Atmos CLI, but within Spacelift. I already have custom image with Atmos in place. The only missing piece seems to be .spacelift/workflow.yml file that would define equivalents for terraform commands. I can create it myself, but I guess someone already did sth similar.

@Dan Miller (Cloud Posse) I think we can expose the spacelift solution from our QuickStart as free snippets in the docs. Cc @Gabriela Campana (Cloud Posse) .

@Michal Tomaszek cannot say when we can get to it, but we’ll update this thread. We will update the docs link above with the snippets.

All this is available out of the box with our QuickStart

it’s already mostly public here https://docs.cloudposse.com/components/library/aws/spacelift/

but we can also publish a specific snippet similar to other snippets

I’ve used all the docs that you guys mentioned. The only missing part really is the .spacelift/workflow.yml config. If you used Atmos as workflow tool within Spacelift stacks, I think you needed this one as it provides wrappers for commands. I specified terraform_workflow_tool: CUSTOM in my stacks/catalog/spacelift/admin-stack.yaml with the intention to use Atmos, so I think it needs additional definitions in .spacelift/workflow.yml. For example standard command for Terraform would be: init: terraform init -input=false and it has to be replaced by: init: atmos terraform init "${ATMOS_COMPONENT}" -s "{{ .WorkspaceName }}" or sth like that - haven’t figured that one yet.

Spacelift internally must be tool agnostic I guess. It just executes whatever it is for init (or any other command). For widely used tools, like Terraform, OpenTofu, etc. the commands are already established internally in Spacelift. For custom tools like Atmos, one has to write configuration explicitly.

@Jeremy White (Cloud Posse) can you share .spacelift/workflow.yml

That isnt a file I’m aware of. Which file are you referring to? Atmos workflow or github actions workflow?

This file is specific to Spacelift, see here

oh I see! Unless I’m missing something, we dont use that configuration file. Perhaps @Jeremy White (Cloud Posse) knows something I dont?

Ah, we used to at least but maybe no longer needed

No, because OIDC solves auth, not network connectivity

If you’re using things like the kubernetes provider and postgres provider, it won’t help

Oh right, it would only work if those resources had public ip addresses