terragrunt-validator

Validate, lint, audit, or check Terragrunt .hcl/terragrunt.hcl files, stacks, modules, compliance.

By akin-ozer · 539 installs

npx skills add akin-ozer/cc-devops-skills --skill terragrunt-validator

Source repository · Upstream listing

Terragrunt Validator Overview This skill provides comprehensive validation, linting, and testing capabilities for Terragrunt configurations. Terragrunt is a thin wrapper for Terraform/OpenTofu that provides extra tools for keeping configurations DRY (Don't Repeat Yourself), working with multiple modules, and managing remote state. Use this skill when: Validating Terragrunt HCL files ( .hcl, terragrunt.hcl, terragrunt.stack.hcl) Working with Terragrunt Stacks (unit/stack blocks, terragrunt stack generate/run ) Performing dry run testing with terragrunt plan Linting Terragrunt/Terraform code for best practices Detecting and researching custom providers or modules Debugging Terragrunt configuration issues Checking dependency graphs Formatting HCL files Running security scans on infrastructure code (Trivy, Checkov) Generating run reports and summaries Terragrunt Version Compatibility This skill is designed for Terragrunt 0.93+ which includes the new CLI redesign. CLI Command Migration Reference Deprecated Command New Command run all run all hclfmt hcl fmt hclvalidate hcl validate validate inputs hcl validate inputs graph dependencies dag graph render json render json w terragrunt info info print plan all , apply all run all plan , run all apply Key Changes in 0.93+: terragrunt run all replaces terragrunt run all for multi module operations terragrunt dag graph replaces terragrunt graph dependencies for dependency visualization terragrunt hcl validate inputs replaces validate inputs for input validation HCL syntax validation via terragrunt hcl fmt check or terragrunt hcl validate Full validation requires terragrunt init && terragrunt validate If using an older Terragrunt version, some commands may need adjustment. Core Capabilities 1. Comprehensive Validation Suite Run the comprehensive validation script to perform all checks at once: What it validates: HCL formatting ( terragrunt hcl fmt check ) HCL input validation ( terragrunt hcl validate inputs ) Terragrunt configuration syntax Terraform configuration validation Linting with tflint Security scanning with Trivy (or legacy tfsec) Dependency graph validation Dry run planning Environment variables: SKIP PLAN=true Skip terragrunt plan step SKIP SECURITY=true Skip security scanning (Trivy/tfsec) SKIP LINT=true Skip tflint linting SKIP INIT=true Skip terragrunt init before validation SKIP BACKEND INIT=true Run init with backend=false (useful in CI/offline) SOFT FAIL SECURITY=true Report security findings without failing TG STRICT MODE=true Enable strict mode (errors on deprecated features) Example usage: 2. Custom Provider and Module Detection Use the detection script to identify custom providers and modules that may require documentation lookup: What it detects: Custom Terraform providers (non HashiCorp) Remote modules (Git, Terraform Registry, HTTP) Provider versions Module versions and sources Output formats: text Human readable report with search recommendations json Machine readable format for automation When custom resources are detected: CRITICAL: You MUST look up documentation for EVERY detected custom resource (both providers AND modules). Do NOT skip any. This is mandatory, not optional. 1. For custom providers: Option A WebSearch: Search for provider documentation Query format: "{provider source} terraform provider documentation version {version}" Example: "mongodb/mongodbatlas terraform provider documentation version 1.14.0" Option B Context7 MCP (Preferred): Use Context7 for structured documentation lookup Step 1: Resolve library ID: mcp context7 resolve library id with provider name (e.g., "datadog terraform provider") Step 2: REQUIRED Fetch docs via mcp context7 query docs with the resolved library ID Use queries like "authentication requirements" and "configuration examples" 2. For custom modules (EQUALLY IMPORTANT DO NOT SKIP): Terraform Registry modules: Use Context7: mcp context7 resolve library id with module name (e.g., "terraform aws modules vpc") Then fetch docs with mcp context7 query docs Or visit https://registry.terraform.io/modules/{source}/{version} Git modules: Use WebSearch with the repository URL to find README or documentation HTTP modules: Investigate the source URL for documentation Pay attention to version compatibility with your Terraform/Terragrunt version 3. Documentation lookup workflow (MANDATORY for ALL detected resources): Example using Context7 MCP: Example using WebSearch: 3. Step by Step Validation For manual or granular validation, use these individual commands: Format Validation Configuration Validation Terraform Validation Linting with tflint Security Scanning with Trivy (Recommended) Note: tfsec has been merged into Trivy and is no longer actively maintained. Use Trivy for all new projects. Alternative: Security Scanning with Checkov Dependency Graph Validation Dry Run Planning 4. Multi Module Operations For projects with multiple Terragrunt modules, use run all (replaces deprecated run all ): 5. HCL Input Validation (New in 0.93+) Validate that all required inputs are set and no unused inputs exist: 6. Strict Mode Enable strict mode to catch deprecated features early: Specific Strict Controls: For finer grained control, use strict control to enable specific controls: 7. New CLI Commands (0.93+) Render Configuration Info Print (replaces terragrunt info) Find and List Units Run Summary and Reports 8. Terragrunt Stacks (GA in v0.78.0+) Terragrunt Stacks provide declarative infrastructure generation using terragrunt.stack.hcl files. Stack File Structure Stack Commands Stack Validation Control Use no validation attribute to skip validation for specific units: Benefits of Stacks Clean working directory : Generated code in hidden .terragrunt stack directory Reusable patterns : Define infrastructure patterns once, deploy many times Version pinning : Different environments can pin different versions Atomic updates : Easy rollbacks of both modules and configurations 9. Exec Command (Run Arbitrary Programs) The exec command allows you to run arbitrary programs against units with Terragrunt context. This is useful for integrating other tools like tflint, checkov, or AWS CLI with Terragrunt's configuration. Key Features: Terragrunt loads the inputs for the unit and makes them available as TF VAR prefixed environment variables Works with any program that can use environment variables Integrates with Terragrunt's authentication context (e.g., AWS profiles) Can be combined with run all for multi unit operations Use Cases: Running security scanners (checkov, trivy) with unit context Executing linters (tflint) per unit Running operational commands (AWS CLI) with correct credentials Custom validation scripts that need Terragrunt inputs 10. Feature Flags (Production Feature) Terragrunt supports first class Feature Flags for safe infrastructure changes. Feature flags allow you to integrate incomplete work without risk, decouple release from deployment, and codify IaC evolution. Defining Feature Flags Using Feature Flags via CLI Feature Flags with run all Benefits: Safe rollouts : Test changes on subset of infrastructure Gradual migrations : Enable new features incrementally A/B testing : Compare infrastructure configurations Emergency rollbacks : Quickly disable problematic features 11. Experiments (Opt in Unstable Features) Terragrunt provides an experiments system for trying unstable features before they're GA: Available Experiments: symlinks Support symlink resolution for Terragrunt units cas Content Addressable Storage for faster Git/module cloning filter flag Advanced filtering capabilities (coming in 1.0) Validation Workflow Follow this workflow when validating Terragrunt configurations: Canonical Executable Workflow (Default Path) Use one executable path so docs and scripts stay aligned: Execution expectations: Fixture tests should be deterministic (stable pass/fail outcomes). Validation/security failures must surface as non zero exits. Step 0: Read Best Practices Reference (MANDATORY FIRST STEP) You MUST read the best practices reference file BEFORE starting validation. This is not optional. This ensures you understand the patterns, anti patterns, and checklists you will verify. Initial Assessment 1. Understand the structure: 2. Identify Terragrunt files: 3. Detect custom resources: Documentation Lookup (MANDATORY for ALL detected custom resources) CRITICAL: If ANY custom providers or modules are detected, you MUST look up documentation for EACH ONE. Do not skip any. 4. For EACH detected custom provider look up documentation: Use Context7 MCP (preferred): 1. mcp context7 resolve library id with provider name 2. mcp context7 query docs with query: "authentication requirements" 3. mcp context7 query docs with query: "configuration examples" OR use WebSearch: "{provider} terraform provider {version} documentation" 5. For EACH detected custom module look up documentation: Use Context7 MCP for Terraform Registry modules: 1. mcp context7 resolve library id with module name (e.g., "terraform aws modules vpc") 2. mcp context7 query docs with relevant configuration query For Git modules: Use WebSearch with repository URL For HTTP modules: Investigate source URL for documentation 6. Document findings for each resource: Required configuration blocks Authentication requirements Known issues or breaking changes in the version Validation Execution 7. Run comprehensive validation: 8. Review output for errors: Format errors → Fix with terragrunt hcl fmt Configuration errors → Check terragrunt.hcl syntax and inputs Terraform validation errors → Check .tf files or generated configs Linting issues → Review tflint output and fix Security issues → Review Trivy/Checkov/tfsec output and address Dependency errors → Check dependency blocks and paths Plan errors → Review Terraform configuration and provider setup Best Practices Check (REQUIRED Must Complete All Checklists) You MUST verify each checklist item below and document the result (✅ pass or ❌ fail). Incomplete verification is not acceptable. 9. Perform explicit best practices verification using references/best practices.md : Configuration Pattern Checklist verify each item: Dependency Management Checklist: Security Checklist: DRY Principle Checklist: Quick grep checks to run: Troubleshooting 10. Common issues and resolutions: Issue: Module not found Issue: Provider authentication errors Check provider configuration in generated files Verify environment variables or credentials Review provider documentation from WebSearch Issue: Dependency errors Check dependency paths are correct Ensure mock outputs are provided for validation Review dependency graph with terragrunt dag graph Issue: State locking errors Issue: S3 backend dynamodb table deprecation warning Recent Terraform versions may warn that dynamodb table is deprecated for S3 backends. Prefer use lockfile = true in backend config when compatible with you