Skip to content

Conversation

@baa-ableton
Copy link

@baa-ableton baa-ableton commented Nov 27, 2025

Description

Fixes #4828 .

It was reported that the prompt was misleading in its wording. 'Apply' for external deps has been replaced with 'install'.

TODOs

Read the Gruntwork contribution guidelines.

  • I authored this code entirely myself
  • I am submitting code based on open source software (e.g. MIT, MPL-2.0, Apache)]
  • I am adding or upgrading a dependency or adapted code and confirm it has a compatible open source license
  • Update the docs.
  • Run the relevant tests successfully, including pre-commit checks.
  • Include release notes. If this PR is backward incompatible, include a migration guide.

Release Notes (draft)

Added / Removed / Updated [X].

Migration Guide

Summary by CodeRabbit

  • Chores
    • Updated external dependency prompt wording from "apply" to "install" for consistency across the product.
  • Documentation
    • Adjusted internal docs and comments to reflect "install" terminology.
  • Tests
    • Updated integration test expectations to match the new prompt wording.

✏️ Tip: You can customize this high-level summary in your review settings.

@vercel
Copy link

vercel bot commented Nov 27, 2025

@baa-ableton is attempting to deploy a commit to the Gruntwork Team on Vercel.

A member of the Team first needs to authorize it.

@coderabbitai
Copy link
Contributor

coderabbitai bot commented Nov 27, 2025

📝 Walkthrough

Walkthrough

Renames a UnitResolver method from confirmShouldApplyExternalDependency to confirmShouldInstallExternalDependency and updates prompt text, variable names, comments, and a test assertion to use "install" instead of "apply" for external-dependency confirmation.

Changes

Cohort / File(s) Summary
Method rename & prompt wording
internal/runner/common/unit_resolver_dependencies.go
Renamed confirmShouldApplyExternalDependencyconfirmShouldInstallExternalDependency; replaced shouldApply identifiers with shouldInstall; changed prompt text from "Should Terragrunt apply the external dependency?" to "Should Terragrunt install the external dependency?"; updated comments/docs and dependency exclusion/AssumeAlreadyApplied logic to reflect install semantics.
Test assertion update
test/integration_destroy_test.go
Updated TestTerragruntSkipConfirmExternalDependencies to assert absence of the new "install" prompt wording instead of "apply".

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~10 minutes

  • Small, consistent rename and wording change across 1 implementation file and 1 test.
  • Areas to check:
    • All call sites and references to the renamed method and identifiers (compile-time/cross-package references).
    • Test output strings and any other user-facing messages or docs that may reference the old wording.
    • Behavior around setting AssumeAlreadyApplied / exclusion semantics to ensure terminology change didn't alter logic.

Suggested reviewers

  • denis256

Pre-merge checks and finishing touches

❌ Failed checks (1 warning)
Check name Status Explanation Resolution
Docstring Coverage ⚠️ Warning Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%. You can run @coderabbitai generate docstrings to improve docstring coverage.
✅ Passed checks (4 passed)
Check name Status Explanation
Title check ✅ Passed The title clearly and concisely identifies the main change: replacing 'apply' terminology with 'install' for external dependency prompts.
Description check ✅ Passed The description references the linked issue #4828 and explains the change motivation; however, release notes and migration guide sections remain incomplete with placeholder text.
Linked Issues check ✅ Passed The code changes directly address issue #4828 by replacing 'apply' terminology with 'install' in prompts, function names, and internal variable logic for external dependencies.
Out of Scope Changes check ✅ Passed All changes are scoped to updating terminology from 'apply' to 'install' for external dependencies; no extraneous modifications detected.
✨ Finishing touches
  • 📝 Generate docstrings
🧪 Generate unit tests (beta)
  • Create PR with unit tests
  • Post copyable unit tests in a comment

📜 Recent review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between b52fcc8 and e38eab6.

📒 Files selected for processing (1)
  • internal/runner/common/unit_resolver_dependencies.go (5 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go

⚙️ CodeRabbit configuration file

Review the Go code for quality and correctness. Make sure that the Go code follows best practices, is performant, and is easy to understand and maintain.

Files:

  • internal/runner/common/unit_resolver_dependencies.go
🔇 Additional comments (1)
internal/runner/common/unit_resolver_dependencies.go (1)

11-59: Rename to shouldInstall and exclusion behavior look consistent

The transition from shouldApply to shouldInstall here is internally consistent:

  • shouldInstall defaults to false, so in all bypass cases (ignoring external deps, non-interactive, no dependent unit, etc.) we still treat the external unit as already handled.
  • unit.AssumeAlreadyApplied = !shouldInstall and if !shouldInstall { unit.FlagExcluded = true } preserve the old behavior: choosing to install runs the dependency, choosing not to install assumes it’s already in the desired state and excludes it from execution.

This aligns with the PR goal of changing user‑facing terminology without altering execution semantics.


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

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

Copy link
Contributor

@coderabbitai coderabbitai bot left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Actionable comments posted: 0

🧹 Nitpick comments (2)
internal/runner/common/unit_resolver_dependencies.go (2)

23-59: Update variable and comment to match new terminology.

While the method call has been correctly updated to confirmShouldInstallExternalDependency, there are two minor inconsistencies:

  1. The variable shouldApply (line 23) still uses the old "apply" terminology
  2. The comment on line 54 says "shouldn't be applied" instead of "shouldn't be installed"

For consistency with the renamed method and updated prompt wording, consider updating these as well.

Apply this diff:

-	shouldApply := false
+	shouldInstall := false

 	if !r.Stack.TerragruntOptions.IgnoreExternalDependencies {
 		// Find a unit that depends on this external dependency for context
 		var dependentUnit *Unit

 		for _, u := range unitsMap {
 			for _, dep := range u.Dependencies {
 				if dep.Path == unit.Path {
 					dependentUnit = u
 					break
 				}
 			}

 			if dependentUnit != nil {
 				break
 			}
 		}

 		// If we found a dependent, ask the user
 		if dependentUnit != nil {
 			var err error

-			shouldApply, err = r.confirmShouldInstallExternalDependency(ctx, dependentUnit, l, unit, unit.TerragruntOptions)
+			shouldInstall, err = r.confirmShouldInstallExternalDependency(ctx, dependentUnit, l, unit, unit.TerragruntOptions)
 			if err != nil {
 				return err
 			}
 		}
 	}

-	unit.AssumeAlreadyApplied = !shouldApply
-	// Mark external dependencies as excluded if they shouldn't be applied
+	unit.AssumeAlreadyApplied = !shouldInstall
+	// Mark external dependencies as excluded if they shouldn't be installed
 	// This ensures they are tracked in the report but not executed
-	if !shouldApply {
+	if !shouldInstall {
 		unit.FlagExcluded = true
 	}

Note: The field name AssumeAlreadyApplied also uses the old terminology, but renaming it would require broader changes across the codebase and is beyond the scope of this PR.


64-68: Update comment to use consistent terminology.

The comment on line 65 still contains "already applied" which should be "already installed" to match the renamed function and updated prompt wording.

Apply this diff:

 // Confirm with the user whether they want Terragrunt to assume the given dependency of the given unit is already
-// applied. If the user selects "yes", then Terragrunt will install that unit as well.
+// installed. If the user selects "yes", then Terragrunt will install that unit as well.
 // Note that we skip the prompt for `run --all destroy` calls. Given the destructive and irreversible nature of destroy, we don't
 // want to provide any risk to the user of accidentally destroying an external dependency unless explicitly included
 // with the --queue-include-external or --queue-include-dir flags.
📜 Review details

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

📥 Commits

Reviewing files that changed from the base of the PR and between 3f8b187 and b52fcc8.

📒 Files selected for processing (2)
  • internal/runner/common/unit_resolver_dependencies.go (4 hunks)
  • test/integration_destroy_test.go (1 hunks)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.go

⚙️ CodeRabbit configuration file

Review the Go code for quality and correctness. Make sure that the Go code follows best practices, is performant, and is easy to understand and maintain.

Files:

  • test/integration_destroy_test.go
  • internal/runner/common/unit_resolver_dependencies.go
🧠 Learnings (1)
📚 Learning: 2025-08-19T16:05:54.723Z
Learnt from: Resonance1584
Repo: gruntwork-io/terragrunt PR: 4683
File: go.mod:86-90
Timestamp: 2025-08-19T16:05:54.723Z
Learning: When analyzing Go module dependencies for removal, always check for both direct imports and API usage across all Go files in the repository, not just a quick search. The github.com/mattn/go-zglob library is used for filesystem walking and glob expansion in multiple Terragrunt files including util/file.go, format commands, and AWS provider patch functionality.

Applied to files:

  • test/integration_destroy_test.go
🧬 Code graph analysis (1)
internal/runner/common/unit_resolver_dependencies.go (4)
options/options.go (1)
  • TerragruntOptions (99-329)
internal/runner/common/unit_resolver.go (1)
  • UnitResolver (47-53)
internal/runner/common/unit.go (1)
  • Unit (26-36)
shell/prompt.go (1)
  • PromptUserForYesNo (65-77)
🔇 Additional comments (4)
internal/runner/common/unit_resolver_dependencies.go (3)

12-12: LGTM: Comment updated appropriately.

The comment correctly reflects the new "install" terminology, which addresses the PR objective of avoiding the misleading "apply" wording.


69-69: LGTM: Function signature updated correctly.

The function has been appropriately renamed from confirmShouldApplyExternalDependency to confirmShouldInstallExternalDependency, maintaining the same signature and preserving all functionality.


88-88: Excellent fix for the misleading prompt wording.

This change directly addresses issue #4828 by replacing "Should Terragrunt apply the external dependency?" with "Should Terragrunt install the external dependency?". The new wording is more accurate because:

  • It doesn't imply that terraform apply will be executed when running plan operations
  • "Install" is more generic and correctly conveys that the dependency will be processed with whatever command is being run (plan, apply, etc.)
test/integration_destroy_test.go (1)

345-345: LGTM: Test assertion correctly updated.

The test assertion has been properly updated to reflect the new prompt wording. This test verifies that the prompt is NOT shown during destroy operations, which is the expected behavior per the logic in unit_resolver_dependencies.go (lines 80-84).

… installing external dependencies

Signed-off-by: Babur Ayanlar <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

When running --all plan prompts contain word "apply" for dependencies

1 participant