Skip to main content

Allow labels on a Module to dynamically attach the correct Context based on Space

Feature RequestsContextsStacksTerraform registry

Take the following scenario:

  • A custom Terraform Module is located in the root Space called alerting-rules. This module interacts with Pagerduty and configures alerting rules. The Module has the label pagerduty assigned to it.

  • We have different Pagerduty credentials per environment

  • We have two Spaces below root called prod and staging which represent our two environments.

  • In each Space, there is a Context called “Pagerduty” with a label autoattach:pagerduty. Each Context defines a PAGERDUTY_TOKEN variable with different values in each environment.

Ideally, I’d like for any Stack which consumes the alerting-rules Module within the prod Space to automatically receive a Context attchment for the “Pagerduty” Context within its Space (and the same for any Stack in the staging Space).

This would remove the need to explicitly attach Contexts directly to Modules and would instead allow different Contexts with the correct labels to be dynamically attached based on the Space in which they’re running.

Workaround
Status: ❌ Rejected3 comments

Log in to comment and vote

Comments3

  • Natalia Gazda

    Team•

    Aug 7, 2025

    Hey @Josh Mills Thanks for this feature request!

    I understand you want Modules to dynamically attach different Contexts based on the Space where they're consumed.This is already achievable using existing Spacelift features. Here's the recommended approach:

    1. Use Space-level Context attachment
    Attach your "Pagerduty" Context directly to the prod and staging Spaces. Any Stack created in those Spaces will automatically inherit the Context.

    2. Use the existing autoattach pattern
    Your current workaround is actually the correct design pattern. Stacks that consume the Module should have the pagerduty label, which triggers Context attachment. This makes the dependency explicit and visible.

    3. Consider Module outputs
    If the Module needs to know about PagerDuty configuration, have the consuming Stack pass it as an input variable rather than trying to dynamically attach Contexts to the Module itself.

    The proposed feature would break the clean separation between Module definition (which should be environment-agnostic) and Module consumption (which is environment-specific). Modules are meant to be reusable templates, not environment-aware components.

    The current pattern where consumers explicitly declare their requirements through labels is more maintainable and follows infrastructure-as-code best practices.

    Would one of these approaches work for your use case?

    • Green Rice

      •

      Aug 11, 2025

      Hi Natlia, thanks for the response. Option 2 works adequately well for us. We tend to have shared modules that are meant to be entirely self-contained so that consumers (development teams) don’t need to know how they actually work, so being able to “hide” the fact that a module requires a pagerduty key would have been nice but I understand your point around explicitness. Thanks!

      • Natalia Gazda

        Team•

        Aug 12, 2025

        Alright, then I hope you are okay with me rejecting the request. Please let me know if there’s anything else I can do!