allow overriding of boilerplate hooks and shell flags in catalog config #4540
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
📝 WalkthroughWalkthroughThis change introduces two new security-related flags, Changes
Sequence Diagram(s)sequenceDiagram
participant User
participant CLI
participant Config
participant ScaffoldEngine
User->>CLI: Run 'terragrunt scaffold' or 'terragrunt catalog'
CLI->>Config: Load config (catalog, scaffold)
Config-->>CLI: Return NoShell, NoHooks values
CLI->>CLI: Parse CLI flags (--no-shell, --no-hooks)
CLI->>CLI: Determine final shell/hooks enablement (CLI flags > config > defaults)
CLI->>ScaffoldEngine: Run scaffold with NoShell/NoHooks flags
ScaffoldEngine-->>User: Generate output (with/without shell/hooks)
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~45 minutes Suggested reviewers
Note ⚡️ Unit Test Generation is now available in beta!Learn more here, or try it out under "Finishing Touches" below. 📜 Recent review detailsConfiguration used: .coderabbit.yaml 📒 Files selected for processing (17)
✅ Files skipped from review due to trivial changes (2)
🚧 Files skipped from review as they are similar to previous changes (15)
✨ Finishing Touches
🧪 Generate unit tests
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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
Documentation and Community
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
config/catalog_test.go (1)
126-168: Well-structured tests with a minor readability improvement suggestion.The test cases comprehensively cover the new scaffold configuration options with clear, descriptive names and inline HCL configurations.
Consider using a cleaner pointer creation syntax for better readability:
-EnableShell: &[]bool{true}[0], +EnableShell: boolPtr(true),You could add a helper function at the top of the test file:
func boolPtr(b bool) *bool { return &b }This would make the test expectations more readable while maintaining the same functionality.
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (17)
cli/commands/catalog/cli.go(1 hunks)cli/commands/scaffold/cli.go(2 hunks)cli/commands/scaffold/scaffold.go(1 hunks)cli/commands/scaffold/scaffold_test.go(1 hunks)config/catalog.go(1 hunks)config/catalog_test.go(2 hunks)docs-starlight/src/content/docs/02-features/06-catalog.md(4 hunks)docs-starlight/src/content/docs/02-features/07-scaffold.md(4 hunks)docs-starlight/src/data/commands/catalog.mdx(1 hunks)docs-starlight/src/data/commands/scaffold.mdx(2 hunks)docs-starlight/src/data/flags/catalog-enable-hooks.mdx(1 hunks)docs-starlight/src/data/flags/catalog-enable-shell.mdx(1 hunks)docs-starlight/src/data/flags/scaffold-enable-hooks.mdx(1 hunks)docs-starlight/src/data/flags/scaffold-enable-shell.mdx(1 hunks)internal/services/catalog/catalog.go(1 hunks)internal/services/catalog/catalog_test.go(1 hunks)options/options.go(2 hunks)
🧰 Additional context used
📓 Path-based instructions (2)
docs-starlight/**/*.md*
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
**/*.go
Instructions used from:
Sources:
⚙️ CodeRabbit Configuration File
🧠 Learnings (7)
docs-starlight/src/data/commands/scaffold.mdx (1)
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
options/options.go (3)
Learnt from: levkohimins
PR: gruntwork-io/terragrunt#3723
File: cli/commands/stack/action.go:160-160
Timestamp: 2025-02-10T13:36:19.542Z
Learning: The project uses a custom error package `github.com/gruntwork-io/terragrunt/internal/errors` which provides similar functionality to `fmt.Errorf` but includes stack traces. Prefer using this package's error functions (e.g., `errors.Errorf`, `errors.New`) over the standard library's error handling.
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#3868
File: docs-starlight/patches/@astrojs%2Fstarlight@0.31.1.patch:33-33
Timestamp: 2025-02-10T23:20:04.295Z
Learning: In Terragrunt projects, all `.hcl` files can be assumed to be Terragrunt configurations by default, with specific exceptions like `.terraform.lock.hcl` that need explicit handling.
cli/commands/catalog/cli.go (1)
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
cli/commands/scaffold/cli.go (1)
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
docs-starlight/src/data/commands/catalog.mdx (2)
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#3868
File: docs-starlight/patches/@astrojs%2Fstarlight@0.31.1.patch:33-33
Timestamp: 2025-02-10T23:20:04.295Z
Learning: In Terragrunt projects, all `.hcl` files can be assumed to be Terragrunt configurations by default, with specific exceptions like `.terraform.lock.hcl` that need explicit handling.
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
config/catalog.go (1)
Learnt from: partcyborg
PR: gruntwork-io/terragrunt#3974
File: config/config_partial.go:448-456
Timestamp: 2025-03-06T23:44:09.413Z
Learning: The TerragruntConfig struct in config/config.go does contain an Engine field that's used to store engine configuration data.
docs-starlight/src/content/docs/02-features/07-scaffold.md (2)
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named `flags` when the `github.com/gruntwork-io/terragrunt/cli/flags` package is imported. Use more specific variable names like `flagSet` instead.
Learnt from: yhakbar
PR: gruntwork-io/terragrunt#3868
File: docs-starlight/patches/@astrojs%2Fstarlight@0.31.1.patch:33-33
Timestamp: 2025-02-10T23:20:04.295Z
Learning: In Terragrunt projects, all `.hcl` files can be assumed to be Terragrunt configurations by default, with specific exceptions like `.terraform.lock.hcl` that need explicit handling.
🧬 Code Graph Analysis (2)
cli/commands/catalog/cli.go (1)
cli/commands/scaffold/cli.go (2)
EnableShellFlagName(21-21)EnableHooksFlagName(22-22)
cli/commands/scaffold/cli.go (2)
cli/flags/flag.go (1)
NewFlag(28-41)internal/cli/bool_flag.go (1)
BoolFlag(13-49)
🔇 Additional comments (29)
cli/commands/catalog/cli.go (1)
21-22: LGTM - Flag filtering logic is correct.The addition of
EnableShellFlagNameandEnableHooksFlagNameto the filter list correctly excludes these scaffold-specific flags from the catalog command, preventing duplication since the catalog has its own versions of these flags.docs-starlight/src/data/commands/scaffold.mdx (3)
11-12: LGTM - Flag documentation is accurate.The addition of
scaffold-enable-shellandscaffold-enable-hooksto the flags list correctly documents the new functionality.
21-26: LGTM - Examples clearly demonstrate the new functionality.The new examples effectively show users how to enable shell functions and hooks during scaffolding, providing clear guidance on the practical usage of these flags.
30-30: LGTM - Usage line correctly includes new flags.The command usage syntax properly includes the new optional flags in the appropriate position.
docs-starlight/src/data/commands/catalog.mdx (2)
17-22: LGTM - Examples clearly demonstrate catalog-specific flag usage.The new examples effectively show how to enable shell functions and hooks when scaffolding from the catalog, providing users with clear guidance on these security-sensitive options.
24-25: LGTM - Flag documentation is complete and accurate.The addition of
catalog-enable-shellandcatalog-enable-hooksto the flags list properly documents the catalog-specific versions of these flags.options/options.go (2)
200-203: LGTM - New scaffold fields are properly defined.The addition of
ScaffoldEnableShellandScaffoldEnableHooksfields with clear comments follows the established patterns in the codebase. The placement near other scaffold-related options maintains good code organization.
442-443: LGTM - Secure defaults are properly initialized.Initializing both
ScaffoldEnableShellandScaffoldEnableHookstofalseensures secure defaults where shell execution and hooks are disabled unless explicitly enabled by the user.internal/services/catalog/catalog.go (1)
108-114: LGTM - Precedence logic correctly implemented.The implementation properly applies catalog configuration for scaffold flags while respecting CLI flag precedence. The null-safety checks for pointer fields and the boolean logic are correct, ensuring that catalog config only takes effect when CLI flags haven't been explicitly set.
cli/commands/scaffold/cli.go (2)
21-22: LGTM: Flag name constants follow established patterns.The new flag name constants are consistent with the existing codebase conventions.
85-97: LGTM: New boolean flags are well-implemented.The new
enable-shellandenable-hooksflags are properly configured with:
- Appropriate environment variable support (
TG_ENABLE_SHELL,TG_ENABLE_HOOKS)- Clear usage descriptions that indicate their purpose
- Proper destination field mapping to the options struct
- Consistent structure with existing flags in the codebase
The implementation follows Go best practices and the established patterns in this codebase.
docs-starlight/src/data/flags/catalog-enable-shell.mdx (1)
1-22: Excellent documentation with appropriate security warnings.The documentation clearly explains:
- The purpose and functionality of the
enable-shellflag- Security implications with a prominent warning about arbitrary command execution
- Clear precedence order for flag resolution
- Practical example usage
The security warning is particularly important given the potential for arbitrary command execution, and it's appropriately emphasized.
docs-starlight/src/data/flags/scaffold-enable-hooks.mdx (1)
1-22: Well-structured documentation with proper security guidance.The documentation effectively covers:
- Clear explanation of hooks functionality in boilerplate templates
- Prominent security warning about the risks of enabling hooks
- Proper precedence order documentation
- Relevant example using the scaffold command
The security considerations are appropriately highlighted, which is crucial for features that can execute arbitrary commands.
docs-starlight/src/data/flags/scaffold-enable-shell.mdx (1)
1-22: Consistent and clear documentation following established patterns.This documentation maintains consistency with the other flag documentation files while providing:
- Clear explanation of shell function capabilities in templates
- Appropriate security warnings about command execution risks
- Well-documented precedence rules
- Practical usage example with the scaffold command
The consistent approach across all flag documentation files enhances the user experience.
cli/commands/scaffold/scaffold.go (1)
204-205: Clean implementation enabling dynamic control of shell and hooks.The change from hardcoded
truevalues to negated flag values (!opts.ScaffoldEnableShelland!opts.ScaffoldEnableHooks) properly implements the feature requirements. This allows users to control shell execution and hooks through CLI flags while maintaining the secure default of having these features disabled.The negation logic is correct since the boilerplate options use "Disable" semantics while the user flags use "Enable" semantics.
docs-starlight/src/data/flags/catalog-enable-hooks.mdx (1)
1-22: Excellent documentation structure and content.The documentation clearly explains the
enable-hooksflag with appropriate security warnings and precedence rules. The structure is well-organized and provides users with the information they need to safely use this feature.config/catalog.go (2)
47-50: Well-designed struct field additions.The use of boolean pointers is appropriate for optional configuration fields, allowing the system to distinguish between unset values and explicitly set false values. The documentation comments clearly explain the precedence behavior with CLI flags.
54-61: Safe and correct String() method implementation.The method properly handles nil pointer cases by using interface{} variables and nil checks before dereferencing. This prevents potential panics while providing meaningful string representation of the configuration.
internal/services/catalog/catalog_test.go (1)
204-302: Comprehensive and well-structured test coverage.The test thoroughly validates the scaffold configuration application with excellent coverage of different scenarios:
- Catalog configuration enabling individual features
- CLI flag precedence over catalog configuration
- Default behavior without scaffold configuration
The table-driven approach with parallel execution and clear test case descriptions makes this maintainable and efficient. The mock setup and assertions are appropriate for validating the integration between catalog configuration and scaffold options.
cli/commands/scaffold/scaffold_test.go (1)
99-245: Excellent integration test for scaffold features.This test provides comprehensive validation of the shell and hooks functionality using actual template processing. The table-driven approach covers all important scenarios:
- Positive and negative cases for both shell and hooks features
- Realistic template content that mimics real-world usage
- Proper validation of expected vs unexpected content in generated files
- Clear test descriptions and assertions
The test effectively validates that the CLI flags properly control the underlying boilerplate template processing behavior.
docs-starlight/src/content/docs/02-features/07-scaffold.md (4)
66-105: Excellent security-focused documentation.The Security Features section effectively communicates the security implications of the new features while providing clear guidance on how to use them safely. The precedence order documentation is particularly valuable for users working with catalog integration.
Key strengths:
- Clear explanation of what each feature does
- Prominent security warnings about arbitrary command execution
- Multiple examples showing different ways to enable features
- Well-structured precedence rules
14-14: Command usage accurately reflects new flags.The updated command usage properly includes the new
--enable-shelland--enable-hooksflags in the expected position within the command syntax.
143-146: Well-documented convenience flags.The new flags are clearly documented with accurate descriptions that emphasize their precedence over catalog configuration. The formatting is consistent with existing flag documentation.
188-198: Practical examples with appropriate security reminders.The new examples clearly demonstrate how to use the security features while reinforcing the importance of caution through comments. This helps users understand both the syntax and the security implications.
docs-starlight/src/content/docs/02-features/06-catalog.md (4)
12-12: LGTM! Clear command syntax documentation.The addition of the new CLI flags to the command syntax follows standard documentation conventions and clearly indicates the flags are optional.
34-38: Excellent configuration documentation with security context.The HCL configuration example is well-structured with clear comments that explain:
- The purpose of each setting
- Default values and security implications
- Override behavior via CLI flags
This provides users with the context they need to make informed decisions about enabling these features.
48-64: Comprehensive and security-conscious documentation.This new section excellently covers:
- Clear explanations of the scaffold configuration options
- Appropriate security warnings about command execution risks
- Well-defined precedence hierarchy
- Good organization with logical subsections
The security emphasis is particularly valuable given the potential risks of enabling shell and hook execution.
76-77: Clear and consistent flag documentation.The flag descriptions are concise and consistent with the earlier documentation, appropriately mentioning the override behavior for catalog configuration.
config/catalog_test.go (1)
190-210: Excellent test implementation following Go best practices.The test execution logic demonstrates good practices:
- Proper test isolation using temporary directories
- Consistent naming with descriptive prefixes
- Appropriate error handling and assertions
- Support for parallel execution
- Clean separation of concerns
The implementation ensures reliable and maintainable test coverage for the new scaffold configuration parsing functionality.
pseudomorph
force-pushed
the
scaffold_override_disable_hooks_and_shell
branch
from
5d39dc2 to
e5b58f6
Compare
pseudomorph
force-pushed
the
scaffold_override_disable_hooks_and_shell
branch
from
e5b58f6 to
54df8fd
Compare
|
Hi, You can run it locally through |
|
Hi, |
|
This functionality has been discussed internally before at Gruntwork, and we previously reached the conclusion that the right way to tackle this functionality in Terragrunt is to introduce a The reason we'd like to bias towards enabling the hooks instead of disabling them is for two major reasons:
Let me know if that makes sense, and if you agree. Sorry I didn't bring this up earlier when you asked about this. |
|
@yhakbar - No problem, shall I invert the logic/options here? |
Yes please |
|
@yhakbar -- qq. do we want a singular flag for both (--no-shell-hooks), or break out for each (--no-shell, --no-hooks) or the exact same flags as boilerplate (--disable-hooks, --disable-shell)? |
Great question. I think we should have two flags for parity, but break parity with the names. Terragrunt flags should always start with Do you agree? |
|
Makes sense! I'll update the PR. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (4)
docs-starlight/src/content/docs/02-features/07-scaffold.md (4)
13-15: Clarify placeholder syntax for flags that take valuesReaders will be unsure what
--var,--var-file, and--root-file-nameexpect. Show the placeholder for the value so the usage string is self-explanatory.-terragrunt scaffold <MODULE_URL> [TEMPLATE_URL] [--var] [--var-file] [--no-shell] [--no-hooks] [--no-include-root] [--root-file-name] +terragrunt scaffold <MODULE_URL> [TEMPLATE_URL] \ + [--var KEY=VALUE...] [--var-file FILE...] \ + [--no-shell] [--no-hooks] [--no-include-root] \ + [--root-file-name NAME]
66-97: Consolidate the security warning into a call-out for better visibilityThe prose repeats the security caution and it can get lost in the middle of the section. Starlight supports admonitions – this draws the reader’s eye and avoids duplication.
-## Security Features - -... - -**Security Note**: Both shell functions and hooks can execute arbitrary commands on your system. Consider disabling these features for enhanced security. Do not scaffold templates you do not trust. +## Security considerations + +:::caution Security note +Shell functions (`{{shell ...}}`) and boilerplate hooks can execute arbitrary commands on your system. +Disable them with `--no-shell` / `--no-hooks` (or the corresponding catalog settings) when scaffolding templates you don’t fully trust. +:::
100-105: Tighten wording & make precedence list unambiguousSmall phrasing tweaks improve readability and make the list easier to scan.
-1. **CLI flags** - `--no-shell` and `--no-hooks` override all other settings -2. **Catalog configuration** - Settings in the `catalog` block (see [catalog documentation](/docs/features/catalog)) -3. **Default values** - Both features are enabled by default +1. **CLI flags** (`terragrunt scaffold --no-shell / --no-hooks`) – highest priority +2. **Catalog configuration** (`no_shell`, `no_hooks` under the `catalog` block) – applied when the CLI flags are omitted +3. **Defaults** – both features are enabled when neither of the above provide an override
175-179: Keep convenience-flag list alphabetised for quick scanningSwapping the two new flags keeps the list ordered and consistent with the existing style.
-- `--no-shell` - Disable shell functions in scaffold templates. Overrides catalog configuration. -- `--no-hooks` - Disable hooks in scaffold templates. Overrides catalog configuration. +- `--no-hooks` - Disable hooks in scaffold templates (overrides catalog configuration). +- `--no-shell` - Disable shell functions in scaffold templates (overrides catalog configuration).
📜 Review details
Configuration used: .coderabbit.yaml
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (11)
cli/commands/scaffold/scaffold_test.go(1 hunks)config/catalog.go(1 hunks)config/catalog_test.go(2 hunks)docs-starlight/src/content/docs/02-features/06-catalog.md(4 hunks)docs-starlight/src/content/docs/02-features/07-scaffold.md(4 hunks)docs-starlight/src/data/flags/catalog-no-hooks.mdx(1 hunks)docs-starlight/src/data/flags/catalog-no-shell.mdx(1 hunks)docs-starlight/src/data/flags/scaffold-no-hooks.mdx(1 hunks)docs-starlight/src/data/flags/scaffold-no-shell.mdx(1 hunks)internal/services/catalog/catalog.go(1 hunks)internal/services/catalog/catalog_test.go(1 hunks)
📓 Path-based instructions (1)
docs-starlight/**/*.md*
⚙️ CodeRabbit Configuration File
Review the documentation for clarity, grammar, and spelling. Make sure that the documentation is easy to understand and follow. There is currently a migration underway from the Jekyll based documentation in
docsto the Starlight + Astro based documentation indocs-starlight. Make sure that thedocs-starlightdocumentation is accurate and up-to-date with thedocsdocumentation, and that any difference between them results in an improvement in thedocs-starlightdocumentation.
Files:
docs-starlight/src/content/docs/02-features/07-scaffold.md
🧠 Learnings (1)
docs-starlight/src/content/docs/02-features/07-scaffold.md (2)
Learnt from: yhakbar
PR: #4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named flags when the github.com/gruntwork-io/terragrunt/cli/flags package is imported. Use more specific variable names like flagSet instead.
Learnt from: yhakbar
PR: #3868
File: docs-starlight/patches/@astrojs%2Fstarlight@0.31.1.patch:33-33
Timestamp: 2025-02-10T23:20:04.295Z
Learning: In Terragrunt projects, all .hcl files can be assumed to be Terragrunt configurations by default, with specific exceptions like .terraform.lock.hcl that need explicit handling.
✅ Files skipped from review due to trivial changes (1)
- docs-starlight/src/data/flags/scaffold-no-shell.mdx
🚧 Files skipped from review as they are similar to previous changes (9)
- internal/services/catalog/catalog.go
- docs-starlight/src/data/flags/scaffold-no-hooks.mdx
- docs-starlight/src/data/flags/catalog-no-shell.mdx
- cli/commands/scaffold/scaffold_test.go
- docs-starlight/src/data/flags/catalog-no-hooks.mdx
- docs-starlight/src/content/docs/02-features/06-catalog.md
- config/catalog.go
- config/catalog_test.go
- internal/services/catalog/catalog_test.go
🧰 Additional context used
📓 Path-based instructions (1)
docs-starlight/**/*.md*
⚙️ CodeRabbit Configuration File
Review the documentation for clarity, grammar, and spelling. Make sure that the documentation is easy to understand and follow. There is currently a migration underway from the Jekyll based documentation in
docsto the Starlight + Astro based documentation indocs-starlight. Make sure that thedocs-starlightdocumentation is accurate and up-to-date with thedocsdocumentation, and that any difference between them results in an improvement in thedocs-starlightdocumentation.
Files:
docs-starlight/src/content/docs/02-features/07-scaffold.md
🧠 Learnings (1)
docs-starlight/src/content/docs/02-features/07-scaffold.md (2)
Learnt from: yhakbar
PR: #4169
File: cli/commands/hcl/validate/cli.go:29-60
Timestamp: 2025-04-17T13:02:28.098Z
Learning: Avoid shadowing imported packages with local variables in Go code, such as using a variable named flags when the github.com/gruntwork-io/terragrunt/cli/flags package is imported. Use more specific variable names like flagSet instead.
Learnt from: yhakbar
PR: #3868
File: docs-starlight/patches/@astrojs%2Fstarlight@0.31.1.patch:33-33
Timestamp: 2025-02-10T23:20:04.295Z
Learning: In Terragrunt projects, all .hcl files can be assumed to be Terragrunt configurations by default, with specific exceptions like .terraform.lock.hcl that need explicit handling.
🔇 Additional comments (1)
docs-starlight/src/content/docs/02-features/07-scaffold.md (1)
219-230: LGTM – explicit examples for the new flags are clearThe additional examples make it obvious how to disable each feature. Nice touch.
|
I bet the test failures are flakes, but the PR now has conflicts. Do you mind addressing them, @pseudomorph ? |
Co-authored-by: rosstr-clickup <rstrickland@clickup.com>
pseudomorph
force-pushed
the
scaffold_override_disable_hooks_and_shell
branch
from
7b92e2f to
e3bbfe7
Compare
|
This has sparked active discussion! We're taking a step back, and changing the way that Boilerplate works in order to try to get the best of both worlds here. We're going to introduce a prompt in Boilerplate whenever a shell function or hook is detected in a template, requiring opt-in from users before running. We'll then cut a breaking change release in Boilerplate, and pull in the updated release to Terragrunt, where that same prompt will be presented to users before a hook/shell is run. That work is going to block merging this in. The |
|
Roger! Sounds like this PR will be unnecessary then. Please lmk if anything is needed from me. |
We can leave it open. Ideally, we can bump the boilerplate dependency, rebase, then merge it in. |
|
Oh, perhaps I misunderstood -- would there would be 2 paths to enable/disable shell/hooks?
If so, would |
Yes. If a user supplied The difference would be that if a user doesn't supply |
Description
Allow overriding the default behavior of disabled shell and hooks for boilerplate in scaffold/catalog.
Fixes #3659.
TODOs
Read the Gruntwork contribution guidelines.
Release Notes (draft)
Added --enable-shell and --enable-hooks CLI flags and catalog configuration support for scaffold templates.
Migration Guide
Summary by CodeRabbit
New Features
--no-shelland--no-hooks, to the scaffold and catalog commands, allowing users to disable shell command execution and hooks in scaffold templates for enhanced security.no_shellandno_hooksboolean settings.Documentation
Tests