Worker launcher should allow to set another default docker image

Currently, if no.spacelift/config.yml file is provided at the repository root, the launcher defaults to the Spacelift image public.ecr.aws/spacelift/runner-terraform:latest, and there’s no way to change that default for all stacks/runs. However, to not force a.spacelift/config.yml file on each repository, and at the same time provide a way for customers to have their own default image for all the runs in a workerpool, the launcher should allow to customize that default image via environment variable (e.g. SPACELIFT_LAUNCHER_DEFAULT_RUNNER_IMAGE)

Expose Run Promotion Flag in Payload

It would be great if you were able to include a Boolean flag for promoted runs in the run portion of the data input payload. This would be useful for crafting plan and approval policies. We allow run promotion to be enabled in environments beyond DEV, but we require special approval for QA and STAGE if it’s not being deployed through the normal PR process. We can typically determine if it was a run promotion by trying to compare the stack’s branch with the run’s branch, but that’s not always possible since setting commit sha with spacectl or other methods sometimes puts “-” as the branch. It would be much simpler to just check if promoted_run: true and that the stack has a qa or stage label to require an approval. Run Promotion - Spacelift Documentation Approval policy - Spacelift Documentation Plan policy - Spacelift Documentation

Support Git Sparse Checkouts

Our Company uses a monorepo. All company code, including terraform, is in this repo. Because of this, the repo is quite large, and can take time to checkout / download. We’d love it if we could sparse checkout the terraform subdirectory since that’s all Spacelift needs. Maybe add it as a stack setting under source control. Scenario: An engineer needs to touch multiple stacks in their PR. That means they need to wait for all stacks to terraform plan before merging. Each stack has to pull their branch and run terraform… which means that every second we can shave off pulling their branch, the faster they can get feedback.

Drift Detection View under stack Overview Page

Currently it’s really difficult to find out where the drift runs are located unless someone is really familiar with the product. I would like to file this feature request to provide a view for drifted runs under stack overview page along with Tracked runs and Ignored runs.

Detect and list stacks with "Deprecated Resource" warnings

Built-in feature to automatically detect and list stacks with "Deprecated Resource" warnings

Show PRs for different Branches in Modules

We noticed that we currently do not see any PRs (and runs for these PRs) that are not the Branch selected under Settings > Source Code > Branch. It would be nice, to have a dropdown or list of pull requests in that whole repository. This would greatly benefit developing code with a single module and an main/develop branching concept.

Support for configuring a Spacelift Stack to "track" a git tag rather than a branch

We have a use case where we want to deploy some infra into multiple environments from a repository that uses git tags to semantically version the infra. By configuring a Stack to point at a git tag rather than a branch we could align the way we use Spacelift to manage this use case with our existing DevOps process. Our use case is a little bit different than Spacelift’s typical use case where a branch is tracked for infra changes. In our case, we’re not planning changes to this infrastructure. We just want to be able to create multiple stacks that deploy this infra into different environments. If (when) we need to make changes to this infrastructure, we will approach this by reconfiguring Stacks to point at a newer git tag.

Spacelift should permit triggering on Git tagging operations

It is a common workflow in other CI systems to trigger runs based on Git tagging operations, whereas Spacelift explicitly ignores them. While that might be the right default behavior, there are cases where it is unexpected and problematic.

Distributed Lock Patterns

Within a stack dependency chain we have stages per environment, separated by external dependencies (UAT & Validation frameworks) that ensure the infra changes are working as expected. Multiple Stacks within the dependency chain align with an environment. As a basic example, Stacks 1-8 are assigned to Test, 9-21 are Pre Prod and 22-35 are Production. Current Spacelift behavior is to queue new runs while another run is active for the same stack, which causes problems when we are updating subsequent stacks within the chain for that same environment (prior to validation). Obviously we do not want new changes going in that effect validation runs. Right now we handle that with a manual trigger for the chain but this is far from ideal. The feature request would be to group stacks within the chain into ‘environment’ blocks where the queue only triggers the next run after the block is complete (including the external dependencies) and remove the need for manual triggers.

Allow viewing long full plan logs directly from web UI

When the full plan logs are too long, you have to download the logs, then view them through a terminal if the logs have ANSI color codes in them. This is all around a confusing experience, between having to leave Spacelift, then figure out how to view the logs. A searchable log viewer that can handle really long log outputs would be nice. We have legacy Terraform stacks that we don’t want to shard before moving them to Spacelift, and sometimes you just end up with a really long plan, no matter how small your stack is.

Tagging Users/Teams with Default Message for Slack Notifications

Currently, if you define a message in a slack notification policy you end up overwriting the default message which includes buttons for user’s to perform actions. It would be nice to be able to prepend or append arbitrary data to the message rather than always overwrite the entire message. For our use-case, we would like to add tagging teams inside the default message, but we can’t do that. Without this ability, it can create a lot of noise for people.

Plan policy reports incorrect `action_initiator` for Bitbucket Datacenter VSC provider

I noticed that the plan policy reports the PR owner not the Person who actually triggered the Merge, I need the person who triggered the merge because at our company they are responsible for applying any affect stacks.

Support dedicating private worker pool for drift detection

This feature adds support for specifying a dedicated private worker pool for drift detection jobs.

Add spacelift_policy_document data source to Provider

It would be nice to be able to reference a spacelift_policy_document data source for the body attribute of spacelift_policy instead of dropping out of terraform to read a file in the filesystem.

Add better support for Terraform/Tofu destroy

We are having issues with the way Terraform/Tofu destroy lifecycle is handled. Currently there are two ways to run a destroy for one of these stacks: Run a task where you manually type in “terraform destroy -auto-approve” Delete the stack and select the option to destroy resources managed by the stack Both of these methods have some obvious downsides: Tasks are not intuitive for operational users of Spacelift that don’t commonly destroy stacks. Destroy lifecycle hooks are not executed as part of tasks so the destroy process may fail or be incomplete when run with a task. Deleting the stack doesn’t support all use cases. In some cases we want to destroy the resources managed by a stack but not the stack itself. We use the stack to create resources again using the same configuration later. Most importantly: both methods to not provide a way for us to review the destroy plan and choose to confirm or reject the destroy. There are many reasons a destroy plan may not be acceptable and the underlying project may need unexpected changes before proceeding. Spacelift already has a nice UX for other parts of the TF lifecycle. We would like to option to trigger a destroy, where the destroy lifecycle is executed with hooks and all, and where we get the opportunity to review the destroy plan and confirm or reject it.

add a terraform provider resource for spacelift_scheduled_run.

TTL for unconfirmed jobs

It would be fantastic if we could TTL unconfirmed jobs into a discarded state. I dislike how a unconfirmed job will block a pipeline and future changes that come in. I understand why its done but if a change is sitting in our default branch I’d want to make sure its out there or reverted.

Private Worker Documentation Enhancement for AWS EC2-based Workers

While documentation clearly states that EC2 instances must be able to reach S3 and public Internet destinations, I believe that the documentation should be more explicit about the need for a NAT Gateway or Egress-Only Gateway. By the way, kudos for making spacelift endpoints reachable by IPv6.

Double quotes in "task" commands should be escaped

Task commands like: terraform state rm module.app_vm.module.vm_ubuntu["gitlab"].solidserver_ip_address.vm_ip_address fail with a somewhat confusing error message: Error: Index value required │ │ on line 1: │ (source code not available) │ │ Index brackets must contain either a literal number or a literal string. because the double quote characters are not escaped. I believe this command would have worked if executed directly at a shell and that Spacelift is doing something like: /bin/sh -c “ ” The wrapping Spacelift quotes interfere with the quotes around the string literal. Thus it would be better if Spacelift automatically escaped (added backslashes) in front of any double quotes found within the submitted task command.

"discard" button placement

I was clicking fast through the “next run” buttons at the bottom of the screen and one at the the top of the stack didn’t have that button so I accidentally clicked discard on a live run. Would be great if that was placed elsewhere