fix(engines): injects suga variable into infrastructure modules

[raksiv]

Adds the suga variable containing infrastructure name and stack ID to the Terraform module configuration.

Required to create unique names for these resources in their respective terraform module implementations.

[coderabbitai]

📝 Walkthrough

Walkthrough

resolveInfraResource in engines/terraform/deployment.go now creates a local sugaVar map containing only "stack_id" set to td.stackId.Result(). This sugaVar is assigned into the TerraformHclModuleConfig Variables field under the key "suga", causing the infra module initialization to receive per-infra stack metadata during resolution.

Suggested reviewers

• jyecusch

Pre-merge checks

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title Check	✅ Passed	The title succinctly describes the injection of the new `suga` variable into infrastructure modules, matching the core change in the PR.
Description Check	✅ Passed	The description clearly explains adding the `suga` variable with stack metadata to Terraform module configurations and its purpose for unique resource names, aligning with the implemented changes.
Docstring Coverage	✅ Passed	No functions found in the changes. Docstring coverage check skipped.

---

📜 Recent review details

Configuration used: CodeRabbit UI

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between ddc5afe and 6f316ba.

📒 Files selected for processing (1)

• engines/terraform/deployment.go (1 hunks)

🔇 Additional comments (1)

engines/terraform/deployment.go (1)

76-84: Add missing name field to suga for consistency.

Other usages of suga include both name and stack_id. Although no references to var.suga.name were found in Terraform modules, update the map to match the pattern:

 sugaVar := map[string]any{
+  "name":     infraName,
   "stack_id": td.stackId.Result(),
 }

Manually verify downstream modules accept this new input.

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[tjholm]

Originally the idea behind not including this was to allow any existing terraform module to be made into infra modules without any additional HCL wrapping. As far as unique naming goes at the moment this can be delegated to SREs (or whoever is performing the apply) by forwarding the name using variables.

Not saying we don't include this by the way, just sharing the original thinking behind not including suga vars for infra.

[raksiv]

yeh lets discuss, I knew that the original intent was to keep suga specific things out of the infra modules - but its not possible to deploy multiple projects that use the same platform config.

[raksiv]

I suppose we could create variables in the default platforms that accept a prefix?

[tjholm]

right, that would be the way to do it currently, could potentially use a few variables as well. e.g.
${var.project_name}-${var.environment_name}-vpc as an example. Built-in variables are also possible.

e.g. ${var.project_name}-${terraform.workspace}, although it might be better to default for those rather than make an assumption i.e. var.environment_name == terraform.workspace as a potential default.

[raksiv]

Okay, I'll pull these and update my platform to use variables.