feat: adds the runtime_overrides variable + tests

[Gowiem]

what

• Adds the runtime_overrides variable + tests to check usage
  • NOTE: The new overrides test is currently failing due to what I'm calling the "Optional Type Defaults Problem". I'm posting this to share the full use-case for what we're running into so I can see if others have an elegant way to handle this problem. Below is the output of the failing tests just so it's easy to find. Check out the OpenTofu Slack thread linked below for full details.
  • (Previously) Failing Test Output
• Introduces StackConfig schema validation using the https://registry.terraform.io/providers/bpedman/jsonschema/latest/docs
• Adds terraform-docs as a trunk action + config for that + removes pre-commit-config

why

• runtime_overrides allows consumers of this child module to do logic within their root module to manage the final Stack config. This gives them additional flexibility beyond our static StackConfig configuration.

references

• Internal Slack Thread on the tests problem
• OpenTofu Community Slack Thread on this issue
• Future path towards not using the jsonschema data source
• jsonschema_validator data source

[gberenice]

LGTM! The only thing that confuses me - this PR contains the changes introduced in the parallel PR #42. Is that intended?

[Gowiem]

@gberenice mind giving me another review? I added a new test to confirm the schema is working as expected 👍

[gberenice]

Great, I like it! Thanks, Matt 👏

[westonplatter]

Will come back and look deeper after a client meeting

[westonplatter]

After watching your rubber 🦆 loom and reading through the open tofu slack thread, I'm wondering if we have a test in this PR for this logic? I didn't see it after a first pass, but I may be overlooking test logic for that condition.

# variables.tf
variable "runtime_overrides" {
  type = object({
    administrative = optional(bool)
    branch = optional_rJemove(string)
  })

  default = {}
}

# terraform.tfvars
runtime_overrides = {
  administrative = false
}

# At runtime
var.runtime_overrides => { administrative = false }

[Gowiem]

@westonplatter This test that you commented on provides just that:

1. We provide a value to runtime_overrides
2. We confirm the values in the underlying resource match the overrides for the stack that we're trying to override.

Specifically for administrative: https://github.com/masterpointio/terraform-spacelift-automation/pull/44/files#diff-42b25f743b9dffd1816864939465621064627de79a1654c58e8f124ca64d66d9R267-R270

Were you looking for something else?

[westonplatter]

Yes, the first test confirms the administrative value, that looks good. I was thinking of a test for how branch is handled - namely, when does it show up in the run_overrides map vs when is it omitted because it is an optional override.

[Gowiem]

@westonplatter tried to explain this clearly here: https://www.loom.com/share/8bd656e02e104ebf87aab6e46ab588fd

[westonplatter]

That loom video helps a lot - I took from it that the type(any) means we are passing in anything, and the mega merge operation drives the final (defaults + any runtime overrides) outcome. There is no expected intermediate data structure with nulls.

The only remaining question I have (and this comes from my rails/web app developer days) is testing that an override doesn't suddenly alter or negatively impact the expected default values.

So in this example, ensure the default value for administrative comes through unaltered by the non-default space_id value.

# Test that the description is created correctly when non-default template string is used
run "test_description_is_created_correctly_when_non_default_template_string_is_used" {
  command = plan
  variables {
    description = "Space ID: $${stack_settings.space_id}"
  }

  assert {
    condition = spacelift_stack.default["root-module-a-test"].description == "Space ID: 123"
    error_message = "Description was not created correctly: ${jsonencode(local.configs)}"
  }

  # new test - ensure the default `administrative` value comes
  assert {
    condition = spacelift_stack.default["root-module-a-test"].administrative == true
    error_message = "Administrative was not created correctly: ${jsonencode(local.configs)}"
  }
}

[westonplatter]

Ah, yeah, the suggested code/test above does not match what I was describing. Ok, after reading the code more, this is that I was trying to get at, #48.

[westonplatter]

The changes I suggested cause a failing. Looks like I don't understand enough of what's going on. Will take another look and follow up tomorrow.

[Gowiem]

@westonplatter your PR doesn't look wrong and I get the test that you're trying to make now. See comment in your PR.

[westonplatter]

Thanks for catching the misnamed variable. I updated it and move the code around a bit, but it's ready to to add to this branch if you're open to testing for that logic situation.

[Gowiem]

@westonplatter glad we got that in! Re-review when you can -- Thanks!

[westonplatter]

Changes look to me. The test coverage was really helpful in understanding the approach and implications of the changes.

[oycyc]

Oh nice cleanup consolidation

[oycyc]

Ty 🙏