archived the channel

We’re archiving this channel as we focus our efforts predominantly on #atmosand our commercial support offerings.

If you’re interested in support for Spacelift, please check out our commercial support services. Existing customers can continue reaching out via your dedicated Slack Connect channels.

https://cloudposse.com/support

Can someone clarify a couple of things about Spacelift for me that I can't find in the docs and my internet searches:
• Is there a problem with using a recent version of Terraform with Spacelift due to the license change?
• What's the difference/value with using Spacelift vs using Atmos with an object storage backend in a generic CICD pipeline?

Upvoted both of those @Michael + @loren -- Good stuff 👍️

FYI, we have a few open Feature Requests open with Spacelift, would love to see some love with them:

1. https://feedback.spacelift.io/p/allow-configuring-log-retention-period
2. https://feedback.spacelift.io/p/audit-logging-run-log-correlation-should-be-consumable-as-one
3. https://feedback.spacelift.io/p/passing-inputs-to-policies-from-hook-scripts -- This is the most relevant for this Slack as it would allow atmos describe affected to drive which Stacks get triggered, which is a huge pain today for large Atmos projects within Spacelift.

Another feature request, can we just eliminate the need to separately create stacks? Drive stack config and runs entirely from source...
https://feedback.spacelift.io/p/drive-a-run-entirely-from-runtime-configuration-no-stack-required

If anyone is interested, I’ve submitted a feature request to Spacelift to add Atmos as a vendor for stack creation. You can vote for it here: https://feedback.spacelift.io/p/incorporating-atmos-into-stack-creation.

Hello,
We have got an issue after this update https://github.com/cloudposse/github-action-atmos-affected-trigger-spacelift/pull/48/files.

The github-action-atmos-affected-trigger-spacelift GHA fails to trigger the affected Spacelift stacks.

Any ideas how to quickly fix it ?

The GHA config:

name: "Deploy Affected Spacelift Stacks"

on:
  pull_request:
    types: [closed]
    branches:
      - main

jobs:
  run:
    if: github.event.pull_request.merged == true
    runs-on:
      group: vnext
    steps:
      - name: Atmos Affected Stacks Trigger Spacelift
        uses: cloudposse/github-action-atmos-affected-trigger-spacelift@v2
        with:
          atmos-config-path: ./rootfs/usr/local/etc/atmos
          deploy: true
          github-token: ${{ secrets.GITHUB_TOKEN }}
          head-ref: ${{ github.sha }}~1
          install-jq: true
          jq-version: 1.7
          atmos-version: 1.153.0

Error:

Hi 👋 I am trying to preview the use of env0 and spacelift for multiple clients - some on vanilla Terraform, some on Terragrunt, and one on atmos. I am finding the UX for setting up a trial unusable. I am getting dropped off at unhelpful screens midway through a GitHub setup journey. Is there someone from spacelift in this chat who can help set me straight?

Seems like spacelift SaaS (non-self-hosted) runners support AWS IAM role assumption using OIDC or even directly without OIDC.

https://docs.spacelift.io/integrations/cloud-providers/oidc
https://docs.spacelift.io/integrations/cloud-providers/aws

Does this mean we no longer need self-hosted runners for managing things like EKS / RDS resources which live inside of our internal VPCs ?

hi, anyone here using Spacelift + Atmos? if so, could you share .spacelift/workflow.yml file? I guess it has to be customized to be able to run Atmos from Spacelift stack.

Cool to see support for MFA now as well! https://spacelift.io/blog/introducing-spacelift-mfa

following up on the discussion on triggering Spacelift admin stacks with GitHub Actions 🧵

I've heard rumor that there's an alleged way of manipulating online workers to allow more room for "burst" runs and not pay billing overages.

I can't figure out how that math might work. Anyone have any insight on how you manage to turn workers on/off to benefit Spacelift billing?

Our basic use case is there's light traffic except for release periods 1-2 times a week for 2-3 hours. So we need maximum throughput for releases, but can have minimal numbers or none a vast majority of the time.

Is anyone using Spacelift, with Terraform versions newer than 1.5.7? Just curious if it's something I have to do install myself in a before_init hook, or if setting terraform_version will do it for me?

The refarch config for the Spacelift admin stacks in each tenant includes the following config (e.g. for plat)

context_filters:
  tenants: ["plat"]
  administrative: false # We don't want this stack to also find itself

We have a few cases where we might want some child stacks for a tenant's admin stack to be administrative
• to create Spacelift terraform resources (e.g. policies or integrations)
• (not yet tried) to create a new admin stack for a child OU of a parent OU (keyed off 'tenant')
Is there a context filter pattern for a tenant's admin stack that allows for administrative child stacks, whilst still not allowing the stack to find itself?

Any thoughts on how Spacelift manages squash commits?

We had a scenario where commit A ran (created 3 ssm params) and commit B ran (deleted those 3).

I've seen some seemingly weird nuance to how commits are handled where it uses hashes from PR and not solely the squash commit id.

is this an issue with the policy or something deeper in spacelift?

Is there any guidance published regarding splitting an admin stack?

context: our plat admin stack is massive now. it handles dev, beta, qa, and prod for a lot of stacks. this takes a long while to run. i'd like to split stacks by stage and am wondering if we would have any issues (namely would stacks destroy and recreate) and if we could just import into the new admin stack.

Upgrade to reconnect this channel

Your team recently switched to a free plan. Spacelift has been removed from this channel. To automatically reconnect this channel, upgrade to a paid plan by Sunday, May 5th.

we just adopted Atlantis, and while it seems to do the job.. we’re not super impressed with its capabilities. we MIGHT look into paid products like spacelift, but curious what a ballpark $ would be for the enterprise plan. I’m sure that’s a hard question to answer without specifics, but some general ballpark #s for an environment like this would be much appreciated:

• self hosted GHA via ARC
• ~ 40 terraform repos
• ~ 40 ish users who submit PRs against those repos, but only 10 ish who actually need to support the infra
TY!

Anyone happen to know if the Spacelift module registry is hosting module versions, or if it is redirecting to the external source? My interest is mostly regarding availability and ref immutability. For example, if the external module is removed would it still be available via my spacelift registry? Or if a tag is removed, does it remain available? What about if a tag is made to point at a different commit? Etc... I don't see anything in the docs about these particular concerns...
• https://docs.spacelift.io/vendors/terraform/module-registry

Note to Spacelift users. Cloud Posse distributed Spacelift configuration scripts that included the line

ln -sfTv /bin/terraform /usr/bin/terraform

Due to changes in Debian and Ubuntu (specifically, replacing the /bin directory with a symlink to /usr/bin, this line should be changed to

[ /bin -ef /usr/bin ] || ln -sfTv /bin/terraform /usr/bin/terraform

Otherwise you will find that the terraform command cannot be found, and you might get an error like

Using Terraform: 
+ which terraform
[01HPMBE7B9D1XJBM622MGSGM46] Unexpected exit code when initializing workspace: 1

I saw that spacelift has Gruntworks' terragrunt native support (Jul 2023).

Is there native support for CloudPosse's atmos on the roadmap? 🙏🏽

Looks like Spacelift AWS images will now be utilizing AL23 as of a week ago

Does spacelift have a feature around "ephemeral" stacks? I.e. automatically destroy after some time period...

@ here, any experience tying in CloudFormation through CP Spacelift components?

Hey folks -- with the spacelift-automation module / component, is there new functionality since 0.49.5 that will cancel stacked "trigger-policy" runs? As in it will do something similar to the below screenshot where if many runs are triggered due to dependencies, only the last will actually be planned?

settings.depends_on is the atmos stack dependency. This does not work for creating spacelift dependencies.

What's the official way to create dependencies in spacelift?

https://atmos.tools/cli/commands/describe/dependents/#description

I'm using atmos and cloudposse/cloud-infrastructure-automation/spacelift, and trying to figure out if the "component instance name" is passed to the spacelift stack anywhere. I'm not super familiar with atmos tbh, the name I'm referring to is the actual key under components.terraform in the stack yaml (not necessarily the name of the component itself). Anyone know if this is something I can get at?

We’re starting to finally do drift detection with Spacelift, just using the default built-in drift detection they offer on private workers. I was curious if any of you use different drift detection tools with Spacelift, and if so, if those tools support provider aliasing and multi-account/region stacks.

Ok, I've moved the blog posts to #spacelift-announcements

Thoughts on splitting this channel into spacelift-announcements and spacelift? The blog posts drownout any conversation.

@dude has joined the channel

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 🧵 ).

Any suggestions on only executing cloudposse/cloud-infrastructure-automation/spacelift after another resource completes?

@Erik Osterman (Cloud Posse) has CloudPosse built any tooling to manage the number of concurrent private workers running?

What Does Terraform Refresh Command Do – Overview
Learn what the Terraform refresh is and why it is recommended not to use this command directly.

Introducing Spacelift Self-Hosted
We are excited to announce that now it is possible to self-host an entire, fully-functional Spacelift platform within your AWS cloud.

How to Migrate From Terraform Cloud to Spacelift
If you want to migrate from Terraform Cloud, we are here to help - learn how you can use our Spacelift Migration Kit to speed up the process.

Introducing Blueprints by Spacelift
Introducing Blueprints by Spacelift - templates for environments that let the administrators configure all defaults, guardrails, and other settings to make it easier for anyone who needs infrastructure to deploy it.

How to Build on AWS with CDK for Terraform (CDKTF)
Explore the Cloud Development Kit (CDK) for Terraform (CDKTF) and how it allows developers to use familiar languages to define their Terraform infrastructure.

Working with Kubernetes Namespaces (Command Reference)
What are Kubernetes namespaces? See how to create them on the command line and in a configuration file.

How to Manage Terraform S3 Backend – Best Practices
Deep dive into using AWS S3 buckets as the remote backend for Terraform and exploring the best practices around the Terraform S3 backend.

How to Create AWS IAM Policy Using Terraform (Tutorial)
See what IAM Policies are, numerous ways to create and manage IAM Policy using Terraform, and how to use them in practice.

Spacelift Module Registry – What It is and How to Use It
See how to use the Spacelift module registry - a private Terraform module registry that is fully compatible with Terraform.

InfraCost – How to Estimate Cloud Cost with Terraform
With Terraform, you can easily estimate cloud costs by leveraging Infracost. Take a look at the Infracost integration with Spacelift.

How to Manage Multiple Terraform Environments Efficiently
Learn how to efficiently manage multiple Terraform environments using Terraform workspaces, Git branches, and Spacelift stacks.

How to Keep Your Playbooks Secure Using Ansible Vault
Explore different options for encrypting sensitive information by leveraging Ansible Vault with examples and use cases of using encrypted content.

Docker Tutorial – Introduction & Getting Started With Docker
What is Docker? How to get started with Docker? See our Docker tutorial for beginners with practical examples of common container management tasks.

What Is Platform Engineering? Role, Principles & Benefits
Learn what platform engineering is and how it differs from DevOps and SRE. With how it benefits your software workflows and best practices.

Managing AWS Security Groups Through Terraform
Deep dive into AWS Security Groups with Terraform. Learn about managing them, network security and more.

OpenShift vs. Kubernetes : Product & Project Comparison
Examine some of the differences between OpenShift and Kubernetes - two popular container orchestration management systems.