Skip to main content

Add a "default labels" setting to the Terraform povider

Feature RequestsSpacelift Provider

Similar to the AWS provider's default_tags provider config, the Spacelift provider should have a default_labels setting that would automatically attach a set of labels to all resources created by it (those that can be labelled, at least).

Also submitted as an issue to the provider repo:

https://github.com/spacelift-io/terraform-provider-spacelift/issues/606

Workaround
Status: ❌ Rejected8 comments

Log in to comment and vote

Comments8

  • Jonah Kowall

    Team•

    Jul 27

    Jonah here, I run product at Spacelift.

    Straight answer first: this is not currently scheduled, and I want to explain why rather than leave it sitting in Discovery indefinitely.


    The feature touches every resource in the provider that supports labels, which is 14 of them. Doing it correctly means adding a computed labels_all attribute across all of them, because a naive merge makes Terraform reject the apply outright. AWS took a long time to get default_tags right for exactly this reason, and a bug in the shared logic would show up as spurious diffs or unexpected label churn in every account at once. That is a real risk to weigh against five upvotes.


    What would change my mind is understanding the problem better. For those of you who upvoted or commented:

    1. What are the labels for? Cost allocation, policy and governance, auto-attach, something else?

    2. How many labeled resources are in your configuration?

    3. Is the shared local variable workaround actually failing, or is it just tedious?

    If governance is the driver, that changes my read significantly. Tell me and I will revisit this.

    • Azure Chipmunk

      •

      Aug 10

      What are the labels for? Cost allocation, policy and governance, auto-attach, something else?

      Lots of different things. Mostly for organizational purposes (e.g. being able to find stacks for X system in Y account that does Z, or “created by X system”).

      How many labeled resources are in your configuration?

      Thousands. Taking one of the labels I would want to set with this feature (`managed_by:spacelift-factory`), there currently 1598 stacks with that label, and that’s only stacks. There’s also at least that many contexts, dozens of policies, etc that all have that label.

      Is the shared local variable workaround actually failing, or is it just tedious?

      In my experience, just tedious. I need to make sure the label(s) are set for every resource explicitly (via a local, usually). This is doable, but it’s prone to mistakes.

      • Jonah Kowall

        Team•

        Aug 13

        Thanks for the numbers, and for saying the local-variable approach works.


        The work here is not scheduled, and the reason is votes rather than difficulty. Eighteen months, five votes, none since January, and you're still the only person describing the problem.

        Correction: I said 14 resources last time. It's 18.


        The trouble is that our labels aren't inert like AWS tags. autoattach:, feature:* and ghenv: change behavior, so one typo in default_labels reattaches policies across every stack you manage. And all 18 resources have to split what the API returns into what you configured versus what the provider added, or you get a permanent diff in every account at once.

        If you found this through #606, ignore the good first issue tag. It's wrong and I'm asking the maintainers to drop it.


        Meanwhile, a plan policy on your factory stack will reject anything missing the label, so a forgotten one fails the run:

        package spacelift

required := "managed_by:spacelift-factory"
labelable := {"spacelift_stack", "spacelift_context", "spacelift_policy", "spacelift_module"}

deny contains sprintf("%s is missing the %q label", [r.address, required]) if {
  some r in input.terraform.resource_changes
  r.type in labelable
  some action in r.change.actions
  action in {"create", "update"}
  not has_required(r)
}

has_required(r) if {
  some l in r.change.after.labels
  l == required
}

        Adapt the list. Won't help where labels are computed at apply.

        I'm closing this out. It can be reopened if it picks up more votes, so keep voting on it.

        • Azure Chipmunk

          •

          Aug 14

          Understandable, thanks!

  • Black Breeze

    •

    May 10, 2025

    Hey! Quick question to understand this better—what’s the actual problem you’re trying to solve with default labels?

    Like, where do the labels go? Are they for billing, automation, tracking… something else? And what happens today if someone forgets to set them?

    Also curious—if the defaults change later, would you expect them to update old stacks too, or just apply to new ones?

    Trying to make sure we solve the right thing here, not just copy AWS for the sake of it.