internal/exec/stack_processor_process_stacks.go (1)

343-355: Consider extracting a shared helper for dependency parse+merge.

The same read/validate/merge sequence is repeated four times. A helper would reduce drift risk and keep precedence/error behavior consistent.

♻️ Refactor sketch

+func readAndMergeDependencies(
+	atmosConfig *schema.AtmosConfiguration,
+	stackName string,
+	globalDeps map[string]any,
+	componentSection map[string]any,
+	invalidSectionErr error,
+) (map[string]any, error) {
+	componentDeps := map[string]any{}
+	if i, ok := componentSection[cfg.DependenciesSectionName]; ok {
+		deps, ok := i.(map[string]any)
+		if !ok {
+			return nil, fmt.Errorf(errFormatWithFile, invalidSectionErr, stackName)
+		}
+		componentDeps = deps
+	}
+
+	return m.Merge(atmosConfig, []map[string]any{globalDeps, componentDeps})
+}

Also applies to: 413-425, 483-495, 553-564

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@internal/exec/stack_processor_process_stacks.go` around lines 343 - 355,
Extract a small helper (e.g., parseAndMergeDependencies) that encapsulates the
repeated read/validate/merge sequence: look up the section map (like
globalTerraformSection[cfg.DependenciesSectionName]), assert it to
map[string]any (terraformDependencies), then call m.Merge(atmosConfig,
[]map[string]any{globalDependenciesSection, terraformDependencies}) and return
the merged map or error; replace each duplicated block (the instances using
globalTerraformSection, globalDependenciesSection, terraformDependencies and
calls to m.Merge) with a call to that helper so precedence and error handling
remain consistent across the four locations.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

tests/terraform_toolchain_integration_test.go (1)

560-634: Prefer a table-driven structure for the precedence scenarios.

This block tests multiple scenarios (override, inherit); converting to table-driven subtests (t.Run) will cut duplication and scale better as precedence cases grow.

♻️ Refactor sketch

-// --- Test component that OVERRIDES Scope 2 at Scope 3 ---
-overrideInfo := ...
-...
-// --- Test component that INHERITS from Scope 1+2 only ---
-inheritInfo := ...
+cases := []struct {
+	name          string
+	component     string
+	expectTF      string
+	expectTFLint  string
+	expectJQ      string
+	expectCheckov bool
+}{
+	{name: "override", component: "test-component-override", expectTF: "1.10.3", expectTFLint: "^0.54.0", expectJQ: "latest", expectCheckov: true},
+	{name: "inherit", component: "test-component-inherit", expectTF: "1.6.0", expectTFLint: "^0.54.0", expectJQ: "latest", expectCheckov: false},
+}
+for _, tc := range cases {
+	tc := tc
+	t.Run(tc.name, func(t *testing.T) {
+		// init config, process stacks, assert merged dependencies
+	})
+}

As per coding guidelines: "Use table-driven tests for testing multiple scenarios in Go."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/terraform_toolchain_integration_test.go` around lines 560 - 634, The
test TestTerraformToolchain_DependencyPrecedence contains two almost-identical
scenarios (override and inherit); refactor it into a table-driven test with
subtests using t.Run to reduce duplication. Create a slice of test cases
describing inputs (ComponentFromArg and expected tool values) and loop over
them, calling cfg.InitCliConfig and exec.ProcessStacks inside each case and
asserting against the case's expected values (use the existing symbols
overrideInfo/inheritInfo only as templates for fields like ComponentFromArg, and
reuse compSection/compSection2 logic inside the loop). Ensure each case has a
descriptive name and keeps the same assertions for tools["terraform"],
tools["tflint"], tools["jq"], and presence/absence of tools["checkov"] so
behavior remains identical.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.

tests/terraform_toolchain_integration_test.go (1)

569-637: Convert precedence scenarios to a table-driven test.

The two scenario blocks are nearly identical; a table-driven subtest matrix will reduce duplication and make future precedence cases easier to add.

♻️ Refactor sketch

- // --- Test component that OVERRIDES Scope 2 at Scope 3 ---
- overrideInfo := schema.ConfigAndStacksInfo{...}
- ...
- // --- Test component that INHERITS from Scope 1+2 only ---
- inheritInfo := schema.ConfigAndStacksInfo{...}
- ...
+ cases := []struct {
+   name          string
+   component     string
+   wantTerraform string
+   wantTflint    string
+   wantJQ        string
+   wantCheckov   bool
+ }{
+   {"override", "test-component-override", "1.10.3", "^0.54.0", "latest", true},
+   {"inherit", "test-component-inherit", "1.6.0", "^0.54.0", "latest", false},
+ }
+
+ for _, tc := range cases {
+   t.Run(tc.name, func(t *testing.T) {
+     info := schema.ConfigAndStacksInfo{
+       Stack:            "override-test",
+       ComponentType:    "terraform",
+       ComponentFromArg: tc.component,
+       SubCommand:       "plan",
+     }
+     atmosConfig, err := cfg.InitCliConfig(info, true)
+     require.NoError(t, err)
+     info, err = exec.ProcessStacks(&atmosConfig, info, true, false, false, nil, nil)
+     require.NoError(t, err)
+
+     deps := info.ComponentSection["dependencies"].(map[string]any)
+     tools := deps["tools"].(map[string]any)
+     assert.Equal(t, tc.wantTerraform, tools["terraform"])
+     assert.Equal(t, tc.wantTflint, tools["tflint"])
+     assert.Equal(t, tc.wantJQ, tools["jq"])
+     _, hasCheckov := tools["checkov"]
+     assert.Equal(t, tc.wantCheckov, hasCheckov)
+   })
+ }

As per coding guidelines: "Use table-driven tests for testing multiple scenarios in Go."

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@tests/terraform_toolchain_integration_test.go` around lines 569 - 637, The
test duplicates two very similar scenarios (overrideInfo and inheritInfo) —
refactor into a table-driven test; create a slice of test cases each containing
fields for ComponentFromArg and expected tools map, then iterate with t.Run per
case and reuse the existing setup: call cfg.InitCliConfig with a
ConfigAndStacksInfo, call exec.ProcessStacks, extract ComponentSection and
dependencies/tools and assert expectations; reference the existing symbols
overrideInfo/inheritInfo only to map their values into table entries, and keep
calls to cfg.InitCliConfig, exec.ProcessStacks, compSection, deps/tools and the
same assertions but driven by the per-case expected values.

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Disabled knowledge base sources:

• Linear integration is disabled

You can enable these sources in your CodeRabbit configuration.