Skip to main content

Support dynamic VCS repository input in Templates

Feature RequestsStacksVCS

Templates currently resolve the VCS repository field at publish time, meaning the repository is baked into the template version and can't be provided as a dynamic input. This prevents using Templates for use cases where the same stack configuration needs to be deployed across multiple repositories - e.g. a "Stack Vendor" template that engineers deploy from to onboard their repo.

Workaround
Problem
Status: 🔭 Discovery5 comments

Log in to comment and vote

Comments5

  • Tan Canteen

    •

    Sep 18

    •

    Merged request

    •

    9 votes

    Conditional enablement of stacks within templates

    We would like the ability to conditionally enable or disable stacks defined in a template based on input values.

    A common use case is selectively deploying optional components, for example via a boolean input such as enable_service_x. When set to false, the corresponding stack should not be created or executed.

    This becomes particularly important in templates that define multiple related stacks, where some components are optional depending on environment, tenant, or feature flags.

    Expected behaviour:

    • Stacks can be conditionally included or excluded based on template inputs.

    • Disabled stacks are treated as if they do not exist for that run.

    • Any dependencies referencing a disabled stack are ignored rather than causing errors.

    • The dependency graph is resolved dynamically after conditions are evaluated.

    • Crimson Toaster

      •

      May 6

      This feature is critical for us. The lack of conditional enablement of stacks within templates is currently blocking our migration from GitLab CI to Spacelift.

      In GitLab, we rely heavily on conditional job execution to control which parts of our pipeline run based on context. Without an equivalent capability in Spacelift templates, we can’t replicate our existing workflows.

      We would greatly appreciate prioritisation of this feature, as it is a key requirement for adoption.

  • Gray Crater

    •

    Apr 23

    Self service templated stack creation is something we would love to have as well. We also use a module to manage our stacks and ensure consistency (i.e. OpenTofu versions, AWS integration attachments, etc.). We currently manage over 250 stacks in this workspace though, so moving this into a self-service Spacelift action would save us from having to do a separate PR and make the whole process a bit less unwieldy from a developer experience perspective.

  • Black Breeze

    •

    Mar 12

    I’ve spoken to our dev team and it’s not a quick fix, and there are side effects. The idea behind templates is that the same code is being deployed to multiple targets. If the code is different, a number of assumptions that we could make no longer holds.

    Perhaps we could schedule a call with our solutions engineering and maybe even someone from the team that shipped templates to explore alternative approaches?

  • Black Breeze

    •

    Mar 12

    Thanks @Jack Leitch for raising this. I’m not yet sure what I think here. On one hand, it makes sense. On the other, making the source dynamic gives us nondeterminism in what’s designed to effectively be a way to deploy the same thing with different config. If we allow changing the source, it’s by design no longer the same thing.

    But before we delve deeper into philosophical aspects of this, I’m running a quick check by my team to see whether it’s technically feasible based on how the backend for Templates works.