#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

Hmm another way to do it would be to connect to an AWS client VPN (or similar) programmatically and pipe the requests through that to connect to private rds or eks

example with github action https://medium.com/@mahmutali.mas/access-private-server-with-github-actions-vpn-connection-cf20313abdd5

I suppose the other options are

• use github actions self-hosted runners for access to private rds/eks (and spacelift for others)

• or the above method to connect to a vpn for access to private rds/eks (and spacelift for others)

• or only provision private rds/eks with terraform using spacelift and configure inside those resources using other means (custom scripts, argocd, etc)

Setting up spacelift with Atmos is a bit of effort.

Our guide for our refarch is here: https://docs.cloudposse.com/layers/spacelift/

Not sure about Terragrunt.

Thank, @Erik Osterman (Cloud Posse). My question was really more about the spacelift.io UI failing with no useful end-user feedback while I was attempting the very first step for setting up a POC. I know spacelift support is not the mission of this channel, but was hoping to find a knoweldgeable/sympathetic ear and to move discussion to DM or email. It’s surely some basic issue with GH/spacelift auth that is unclear/encapsulated away from the UX

@James Humphries can maybe direct you to the right person

Hey! sorry for the late reply, its evening for me now. I’m one of the engineering team leads at spacelift so hopefully I can help!

I’ve also sent this on to our support team, it may be best if you reach out to them directly. I think you can use the speech bubble in the corner of our page and someone should be able to help or you can email [email protected]

As you’re here though: Im currently unaware of any issues with the github signup. I’d be happy if you wanted to share some more details or maybe screenshots/recordings in a DM and I can see what I can do to help this weekend!

Thanks @James Humphries and @Erik Osterman (Cloud Posse). I’m in touch with the support team. I’ll see how that plays out.

Please reach out to me if it slows down at all (It shouldn’t, our support team is amazing!), i’ll be sure to be on their case as much as I can be