Skip to main content

Make discarding multiple runs more flexible

Feature RequestsIaC Workflows

The current way to discard multiple runs at once is not flexible enough - let’s say, that some changed triggered 10 stacks/runs, but we want only 2 runs to be executed. Hence, we want to discard 8 specific runs - right now we need to open each run in the new card and discard them one by one. It would be great to have some way to discard multiple (but not all) runs triggered by the same commit.

For example: in the “Runs” dashboard I click on some commit (“Commits” row) or just filter it, and a tickbox to the left of stack’s name would appear - and we could discard selected runs.

Status: ✅ Completed3 comments

Log in to comment and vote

Comments3

  • Black Breeze

    •

    Sep 10, 2025

    Thanks for sharing this feature request! I can see you're dealing with a common scenario where a single commit triggers multiple runs, but you only want to execute a subset of them.

    Before we explore solutions, I'd like to understand your workflow better:

    What's driving this pattern?

    • Are these 10 stacks in a monorepo where most changes don't affect all stacks?

    • Is this about deployment sequencing where you want to test changes in specific environments first?

    • Or is it more about resource management - avoiding unnecessary runs that would consume worker capacity?

    What makes you decide which 2 runs to keep?

    • Is it based on which files changed?

    • The criticality of certain stacks?

    • Dependencies between stacks?

    • Something else?

    How often does this scenario occur?

    • Is this a daily friction point or more occasional?

    • Would preventing the unwanted runs from being created in the first place be better than discarding them after?

    Understanding these patterns will help us design the right solution. For instance, we might be able to leverage push policies to be more selective about which runs get created, or we could explore bulk operations in the UI as you suggested.

    What would the ideal workflow look like for your team?

    • Azure Chipmunk

      •

      Oct 28, 2025

      Not the OP, but I can provide my own feedback on what I’d like to see improved: the ability to “discard all but the most recent run”. We have some stacks which are not set to auto-apply, but may get runs triggered for a very busy repo. Most of those triggered runs would result in no changes. If a run is triggered that does have changes, but it doesn’t get approved/confirmed, it’ll sit there waiting for approval while new runs pile on top of it (in the “queued” state). When someone finally does get to reviewing the plan and approving it, all those subsequent plans need to either be discarded one-by-one or allowed to plan. This could be for dozens of runs. It’d be nice to have a button on a “queued” plan to discard all other runs before it and just run this one.

    • Purple Teacup

      •

      Nov 24, 2025

      Sorry for late response, I missed an email.
      @Marcin Wyszynski yszynski answering your questions:

      Are these 10 stacks in a monorepo where most changes don't affect all stacks?
      Kinda yes, kind no. We’re using monorepo, but it is grouped by environment. A more specific example would be:
      We modify a file (e.g. version of Terraform module) that is tracked by 10 stacks (in our case, we version Terraform modules per environment - and each stack responsible for creation of VM is using tracked_path label set to the path of file where version of Terraform module is set). This would trigger 10 runs. And let’s say that we expect no changes after bumping a module, but in case of 2 stacks - there is. So we adjust variables for those 2 resources, create commit/amend and push force, this trigger another 10 runs - but we are only interested in 2 specific runs, to check if there is no drift anymore (and since we didn’t touch/modified anything else, we are sure, that there is no drift for another 8 stacks).


      Is this about deployment sequencing where you want to test changes in specific environments first?

      Wouldn’t call it like this

      Or is it more about resource management - avoiding unnecessary runs that would consume worker capacity?

      Yes, saving time (don’t have to wait for extra 8 runs that are unnecessarily triggered) is a primary factory

      What makes you decide which 2 runs to keep?

      That only those 2 runs reported a drift, and we want to fix it in the next commit(s) - and execute proposed runs only for those 2

      How often does this scenario occur?

      Maybe a dozen times a month

      What would the ideal workflow look like for your team?
      Ideally, Spacelift would detect that no files related to a given stack were changed in the new commit (on the same PR branch), so it wouldn’t trigger extra 8 runs, as the previous “round of runs” already found, that there were no changes found