Skip to content

chore(deps): update gruntwork-io/terragrunt to 1.0.5#107

Open
zon-renovate wants to merge 1 commit into
mainfrom
renovate/gruntwork-io-terragrunt-1.x
Open

chore(deps): update gruntwork-io/terragrunt to 1.0.5#107
zon-renovate wants to merge 1 commit into
mainfrom
renovate/gruntwork-io-terragrunt-1.x

Conversation

@zon-renovate
Copy link
Copy Markdown
Collaborator

@zon-renovate zon-renovate commented Apr 18, 2026 •
edited
Loading

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package Update Change
gruntwork-io/terragrunt patch 1.0.0 → 1.0.5

Release Notes

gruntwork-io/terragrunt (gruntwork-io/terragrunt)

v1.0.5

Compare Source

✨ New Features

Full .terraform.lock.hcl files from the provider cache server

When the provider cache server is used against the OpenTofu provider registry, Terragrunt now writes .terraform.lock.hcl files containing h1: hashes for every platform the registry supports. A single terragrunt init produces a lock file that works on every platform, removing the need to run tofu providers lock -platform=... separately for each target architecture.

provider "registry.opentofu.org/hashicorp/null" {
  version     = "3.2.2"
  constraints = "3.2.2"
  hashes = [
    "h1:+1mRmfyz6oA00IhrrSkHK3h/Mdh032x2p0F6OMdMo5s=",
    "h1:FjLTqvaaYo+vHN8pHZB1cOwEGiNzOj+I9kQyHmr9/7o=",
    # ... one entry per supported platform ...
    "zh:00e5877d19fb1c1d8c4b3536334a46a5c86f57146fd115c7b7b4b5d2bf2de86d",
    # ... one entry per supported platform ...
  ]
}

The hashes come from the registry's per-platform download response. When the registry does not supply them (for example, a third-party registry that has not adopted the field), Terragrunt falls back to its previous behavior of writing an h1: hash for the current platform plus zh: hashes for every platform listed in the shasums document.

[!TIP]
Thanks to the OpenTofu team

This feature builds on work done by the OpenTofu team to expose per-platform hashes directly from the OpenTofu provider registry. Starting with OpenTofu 1.12, tofu init populates .terraform.lock.hcl with hashes for every supported platform out of the box, with no tofu providers lock invocation required. Users on older OpenTofu versions still get the same lock files when running through Terragrunt's provider cache server, but upgrading to 1.12 is the easiest way to get the same behavior everywhere, including when using the automatic provider cache dir.

🏎️ Performance Improvements

stack output fetches unit outputs in parallel

terragrunt stack output now fetches outputs from multiple units at the same time, which is noticeably faster on larger stacks. Use the existing --parallelism flag (or TG_PARALLELISM) to lower concurrency if you need to.

terragrunt stack output --parallelism 4

💡 Tips Added

Stack-target hint when --filter is missing | type=stack

run and stack generate now emit a tip when a --filter path resolves to a directory containing terragrunt.stack.hcl but the filter is not restricted to stacks. Without | type=stack, stack generate ignores the filter and run does not generate that stack.

The tip prints the offending filter, the suggested rewrite, and a link to the filter docs. Suppress it with --no-tip stack-target-missing-type-stack or --no-tips.

🐛 Bug Fixes

Auth provider command returning null no longer crashes Terragrunt

If the command configured via --auth-provider-cmd wrote the JSON value null to stdout, Terragrunt crashed with a nil pointer dereference before it could obtain credentials.

A null response is now treated as an empty response: no environment variables and no credentials are applied, and the run continues.

Auto-init now re-runs after a source change when modules are already cached

terragrunt plan/apply could fail with Error: Required plugins are not installed after a source-version change in any unit with a module "" block. The .terragrunt-init-required marker written on source change was being ignored because modulesNeedInit short-circuited as soon as .terraform/modules/ existed.

The marker check now lives at the top of needsInitRunCfg and is honored regardless of cached .terraform/modules/ contents.

Thanks to @​arnaud-dezandee for contributing this fix!

--download-dir is now respected through dependency blocks and read_terragrunt_config

A custom download directory set via --download-dir (or TG_DOWNLOAD_DIR) was honored for the unit being run, but lost as soon as parsing crossed into another config. dependency blocks and read_terragrunt_config() would fall back to the dependency's local .terragrunt-cache next to its terragrunt.hcl, ignoring the user-set path.

TG_DOWNLOAD_DIR=/tmp/tg-cache terragrunt run --all plan

# Root unit: outputs landed in /tmp/tg-cache ✓
# Dependency outputs: written next to each dependency's terragrunt.hcl ✗

When the parsing context switches to a new config path, the download directory is now updated only if it still points at the previous module's default location. A user-supplied path never matches any module's default and is carried through every dependency hop unchanged.

Thanks to @​maonat for contributing this fix!

remote_state — apply tags during DynamoDB lock table creation

Terragrunt previously applied dynamodb_table_tags to DynamoDB lock tables after table creation rather than during the initial CreateTable API request.

This caused failures in environments enforcing required AWS resource tags through SCPs or tag policies, where tags must be present at resource creation time.

Terragrunt now includes dynamodb_table_tags in the initial DynamoDB table creation request during remote state bootstrap.

remote_state {
  backend = "s3"

  config = {
    bucket         = "my-state-bucket"
    dynamodb_table = "terraform-locks"

    dynamodb_table_tags = {
      Environment = "prod"
      Team        = "platform"
    }
  }
}

Thanks to @​Rahul-Kumar-prog for contributing this fix!

Engine archive extraction rejects path-traversal entries

When Terragrunt extracted an engine archive while the engine experiment was active, entries whose target path resolved outside the extraction directory were not rejected correctly. Such an entry could overwrite files anywhere the Terragrunt process could write.

These entries are now rejected early with a descriptive error before any bytes are written. Engine archives produced by Gruntwork were never affected; the gap only mattered for a tampered or untrusted archive.

Thanks to @​jackiesre721 for reporting this!

--filter combined with a negation no longer parses excluded units

When a positive path filter was combined with a negated one, Terragrunt classified any unit that matched neither expression as requiring defensive parsing before exclusion instead of being excluded early.

e.g.

$ terragrunt run --all --filter './foo' --filter '!./baz'

# If `./bar` existed on disk, it would be parsed before being excluded. This is no longer the case.

Any positive filepath filter now consistently results in units that cannot be discovered during Terragrunt discovery being excluded from parsing for evaluating candidacy of inclusion. When a sufficiently complex filter is present, like the following:

$ terragrunt run --all --filter './foo' --filter '!./baz' --filter 'reading=root.hcl'

# If `./bar` existed on disk, it will still be parsed before being excluded to determine if it reads `root.hcl`.

macOS and Windows binaries report the correct release version

The v1.0.4 macOS and Windows release binaries reported terragrunt version main and parsed as 0.0.0, breaking any terragrunt_version_constraint configured against them.

sign-macos.yml and sign-windows.yml included build jobs for standalone workflow_dispatch runs. During the release workflow, those jobs still saw the original workflow_dispatch event from release.yml, so the old condition evaluated to true. The redundant build used BUILD_VERSION=${{ github.ref_name }} and replaced the correctly versioned artifact uploaded by build.yml.

The signing workflows now skip their internal build job when invoked via workflow_call and only build when dispatched directly, so release binaries keep the version stamped by build.yml.

Fixed 403 Forbidden on nested private modules when using the provider cache server

With TG_PROVIDER_CACHE enabled, OpenTofu/Terraform sent nested module-registry lookups to the upstream registry with the cache server's API key as the bearer token, instead of the credentials configured for that host. Private registries rejected those requests:

Error: Error accessing remote module registry

Failed to retrieve available versions for module "<name>" from
<registry>: error looking up module versions: 403 Forbidden.

Terragrunt sets TF_TOKEN_<host> to the cache server's API key so the cache can front provider downloads. Module-registry requests bypassed the cache and went straight to the upstream, so the registry saw the cache key instead of the user's token.

The cache server now also fronts the modules.v1 endpoint for each configured registry. It drops the inbound cache-server bearer, looks up the user's credentials for the upstream host from the loaded CLI config (TF_TOKEN_<host>, ~/.terraform.d/credentials.tfrc.json, etc.), and forwards the request with that token.

Run report file generation no longer stalls or deadlocks with many runs

Generating a run report via --report-file could stall or deadlock when a queue contained many runs and some were still recording their final status as the report was written.

Reports now serialize each run independently, so writing a report no longer blocks status updates from runs that are still finishing.

Thanks to @​jackiesre721 for contributing this fix!

Declining a run --all or --graph confirmation no longer skips cleanup

When terragrunt run --all destroy (or --all state, --all apply, or the equivalent --graph variants) prompted for confirmation and the user answered "no", Terragrunt terminated the process directly, skipping cleanup the run had registered.

Cleanup now runs before Terragrunt exits.

s3:: and gcs:: stack sources now download

Stack file source URLs starting with s3::https:// or gcs::https:// previously failed with a credentials error even when valid credentials were available. They now download. Existing stack files need no change.

Plain https://www.googleapis.com/storage/... URLs are now intended to download anonymously without GCP credentials, but Terragrunt continues to use GCS credentials to download them for backward compatibility, emitting a deprecation warning the first time it does so. To opt into the new behavior, enable the legacy-gcs-public-prefix strict control. To pull from a private GCS bucket explicitly, prefix the URL with gcs:: yourself.

Fixed nested key order in terragrunt stack output

When a unit lived inside more than one nested stack, terragrunt stack output rendered its key with the stack names reversed, so a unit inside root_stack_3 > stack_v3 > stack_v2 appeared under stack_v2.stack_v3.root_stack_3 instead of root_stack_3.stack_v3.stack_v2. Deeply nested units also leaked to the top level of the output.

The output now joins stack names from outermost to innermost, matching the declared hierarchy in both the HCL and JSON formats.

Thanks to @​anuragrao04 for contributing this fix!

Fixed failed to create directory ...: file exists from the provider cache server

If a previous run had cached a provider by symlinking ~/.terraform.d/plugins/<provider> into Terragrunt's own provider cache, and that user plugin directory was later moved or deleted, the symlink was left dangling. The next run failed with failed to create directory ...: file exists and refused to cache the provider.

Terragrunt now removes a dangling symlink at the cache path on the next run and proceeds to download the provider. A non-symlink at that path is left in place and surfaced as an error.

🧪 Experiments Added

azure-backend — Native Azure Storage (azurerm) remote-state support

The azure-backend experiment has been added as the gate for native Terragrunt support of the Azure Storage (azurerm) remote-state backend. Once it stabilizes, Terragrunt will bootstrap, delete, and migrate Azure storage accounts and blob containers the same way it already does for S3 and GCS, and read state directly from Azure blobs for --dependency-fetch-output-from-state.

In this release the flag is reserved only. Enabling it has no behavioral effect, and remote_state { backend = "azurerm" } continues to pass through to the OpenTofu and Terraform native azurerm backend.

Track progress and share feedback in #​4307. For setup steps, see the experiment documentation.

Thanks to @​omattsson for driving this experiment forward!

🧪 Experiments Updated

CAS keeps a central Git store for incremental fetches

CAS now keeps one bare Git repository per remote URL inside its store, under ~/.cache/terragrunt/cas/store/git/ on Linux by default. See Storage for where this lives on macOS and Windows. On a cache miss, Terragrunt fetches just the requested ref into that repository instead of running a fresh shallow clone into a temporary directory. Repeated misses against the same remote reuse the existing pack files, so fetching a second ref from the same repository transfers only the new objects.

Concurrent Terragrunt runs against the same remote URL share one fetch instead of cloning in parallel; later runs reuse what the first one transferred. If the shared fetch hangs or fails, Terragrunt logs a warning and falls back to a temporary clone so cloning still succeeds.

You can reclaim space at any time by deleting the git/ subdirectory:

rm -rf ~/.cache/terragrunt/cas/store/git

cas — Commit SHAs accepted in ref=

Source URLs of the form git::<url>?ref=<commit-sha> now resolve through CAS. Previously these clones failed because Terragrunt asked the remote to look up the SHA as a symbolic reference, which Git servers don't support.

Both full SHAs (SHA-1 and SHA-256) and abbreviated SHAs are accepted. Abbreviated SHAs must disambiguate inside the repository, the same rule Git itself applies.

terraform {
  source = "git::https://github.com/acme/infrastructure-modules.git//vpc?ref=a1b2c3d4e5f67890abcdef1234567890deadbeef"
}

The first cold clone of a repository pinned to a commit SHA fetches the full history of every branch. Shallow fetches require a ref name, and fetching a commit SHA at limited depth depends on a server option (uploadpack.allowAnySHA1InWant) that is not universally enabled, so CAS fetches all branches at full depth and resolves the SHA locally. Subsequent clones reuse the cached repository and never touch the network for the same commit. Branch and tag refs continue to use the existing shallow path.

cas — mutable attribute on terraform, unit, and stack blocks

A new mutable attribute opts a block out of CAS hardlinking when its source is fetched through CAS. With mutable = true, files materialized into .terragrunt-cache (for terraform) or .terragrunt-stack (for unit and stack) are copied from the CAS store and the working tree is editable.

The default is false. Files are materialized read-only so an accidental edit cannot reach back into the shared CAS store.

terraform {
  source  = "git::https://github.com/acme/infrastructure-modules.git//vpc?ref=v1.0.0"
  mutable = true
}

The flag is orthogonal to update_source_with_cas and has no effect when content is fetched through the standard download path, which already produces an independent copy.

cas — update_source_with_cas now idempotent across unit and stack blocks

A terragrunt.stack.hcl with two blocks pointing at the same template directory used to fail stack generate when each block had update_source_with_cas = true. The first block's pass rewrote the shared template's source to a cas::sha256:... reference, then the second block's pass re-read the rewritten file and treated the reference as a relative path.

CAS now skips re-processing a source once it already carries the cas:: prefix, so multiple unit or stack blocks can share a template and resolve to the same synthetic tree.

cas — symlinks in the source repository

Source repositories fetched through CAS used to materialize committed symlinks as regular files whose contents were the link target path. The destination tree no longer matched the upstream layout, and any tooling that followed the link saw plain text instead.

CAS now writes a real symbolic link at the destination. Symlink targets that resolve outside the destination tree are rejected so a hostile or stale source cannot escape the working directory.

catalog-redesign — component tags

The catalog-redesign experiment now reads a tags field from the component's README.md front-matter. Tags appear as colored pills next to the component in the list view and in the detail view above the rendered README.

<!-- Frontmatter
name: VPC App
description: A VPC for application workloads.
tags: [networking, aws, module]
-->

Either inline-array or dash-list YAML form is accepted. Tags render in gray by default. When a tag matches a known component-type name (module, template, unit, or stack, case-insensitive), the pill takes on that type's color.

A tag matching a component-type name also promotes the component into that type's tab. A template whose tags include module appears under both Templates (by its native kind) and Modules (by tag), without changing how it scaffolds.

To learn more, see Component tags.

What's Changed

New Contributors

Full Changelog: gruntwork-io/terragrunt@v1.0.4...v1.0.5

v1.0.4

Compare Source

🏎️ Performance Improvements

run_cmd and Git repo-root results memoized without the Provider Cache Server

Within a single command, repeated run_cmd(...) calls and repeated Git repo-root lookups across units used to share their cached results only when the Provider Cache Server was running. Commands invoked without --provider-cache (the common case for find, list, and run --all against estates that do not need provider caching) re-evaluated each run_cmd and re-shelled to git rev-parse --show-toplevel for every unit.

Both caches are now active for every command, so identical run_cmd arguments and repeated repo-root lookups are reused across units regardless of whether the Provider Cache Server is enabled.

fast-copy strict control

With the new fast-copy strict control enabled, Terragrunt compiles each include_in_copy and exclude_from_copy pattern once and evaluates it inline during a single copy walk. This avoids re-walking subdirectories for every pattern, which should result in noticeable speed improvements for large source modules.

terragrunt run plan --strict-control fast-copy

The new matcher does not collapse ** to zero path segments when a neighbor is a wildcard, so a/**/*.tf matches a/sub/main.tf but not a/main.tf. Patterns that relied on the old collapsing behavior should use brace alternation like {*.tf,**/*.tf} to cover both depths.

Fewer git rev-parse invocations on large estates

The get_repo_root() HCL function, the runner, and the find and list discovery commands all ask Git for the enclosing repository root. Previously, two units in the same repository each triggered their own git rev-parse --show-toplevel, even when the answer was identical. On large estates this added up to one fork per unit (and sometimes more) for a value that never changed.

A repository discovered for one working directory is now reused for any other working directory inside it, for the duration of the command. Nested repositories (a checkout vendored inside another) still resolve to their own root.

🐛 Bug Fixes

--auth-provider-cmd no longer runs once per dependency cache directory

Resolving dependency outputs ran the configured --auth-provider-cmd again from inside each .terragrunt-cache working directory, on top of the call already made for the unit.

Terragrunt now reuses the credentials already obtained for the dependency when reading outputs from a cached working directory, so --auth-provider-cmd is invoked once per dependency instead of twice.

Fixed exclude block being dropped when defined only in an included parent

A unit that pulled in an exclude block from an include that did not declare its own exclude block saw the include's exclude configurations ignored.

Included exclude blocks now get properly merged into unit configurations.

Reported in #​5089. Thanks to @​HeikoNeblung for contributing this fix!

Fixed terragrunt find --include failing on relative include paths

Running terragrunt find --include against units whose include blocks reference parent configs with relative paths (../root.hcl, ./common.hcl, bare filenames, etc.) emitted errors like Rel: can't make ../root.hcl relative to /abs/working-dir and dropped those entries from the output.

Relative include paths are now resolved against the unit's directory before being made relative to the working directory, matching how the rest of Terragrunt interprets the path attribute on an include block.

find and list no longer hard-fail when a path cannot be made relative to its base. The condition is logged as a warning and the path is emitted as-is, so output stays complete and the command exits zero.

Tolerate non-JSON warnings in tofu/terraform output -json

Resolving dependency outputs no longer fails when the underlying tofu/terraform output -json invocation prints a deprecation warning to stdout alongside the JSON payload. Terraform 1.15.0 introduced a backend deprecation warning for the S3 dynamodb_table parameter that is emitted on stdout after the JSON object, which broke parsing with errors like invalid character 'W' after top-level value and the misleading downstream message There is no variable named "dependency".

Terragrunt now isolates the first JSON object in the captured stdout, so leading log lines (for example, the long-standing AWS Client Side Monitoring Enabling CSM line) and trailing warning blocks are both ignored when reading dependency outputs.

Resolves #​6001. Thanks to @​jpke for contributing this fix!

get_repo_root() returns OS-native separators on Windows

git rev-parse --show-toplevel always emits forward-slash paths, even on Windows. Terragrunt returned that string unchanged from get_repo_root(), so configurations that compared the result against path/filepath-style paths or fed it back into helpers expecting OS-native separators saw spurious mismatches and broken joins on Windows.

The output is now normalized to OS-native separators before being returned, so get_repo_root() produces C:\repo\path on Windows and /repo/path on Linux and macOS.

Reported in #​5976.

Hardened module manifest handling

Terragrunt now bounds .terragrunt-module-manifest cleanup to the manifest's own folder, skips paths with symlinked parents, and removes invalid manifests after reading any valid entries. Existing manifests keep the same gob format.

Provider Cache Server now supports custom host blocks

Running terragrunt with the Provider Cache Server enabled against a private registry declared via a host block in .terraformrc (or a file referenced by TF_CLI_CONFIG_FILE) failed with errors such as provider registry.opentofu.org/<org>/<provider> was not found, because the cache server proxy did not recognize the custom registry and rewrote requests to registry.opentofu.org.

Terragrunt now registers each custom host block with the cache server, seeds its service discovery from the services map so registries that do not serve .well-known/terraform.json still work, and forwards OPENTOFU_NETRC_* / TF_TOKEN_* credentials so authenticated registries continue to authenticate through the proxy.

# .terraformrc
host "registry.example.com" {
  services = {
    "providers.v1" = "https://registry.example.com/repository/terraform-hosted/v1/providers/"
  }
}

Resolves #​5916. Thanks to @​elkh510 for contributing this fix!

🧪 Experiments Updated

stack-dependencies — Stricter validation and clearer parse errors for autoinclude

Malformed configuration inside an autoinclude block previously produced misleading messages or, in some cases, was silently ignored during stack discovery.

Two changes tighten this up:

  • A dependency block inside autoinclude must declare exactly one label. Zero labels (dependency {}) and multiple labels (dependency "a" "b" {}) are now rejected at parse time with a diagnostic that points at the offending block.
  • Parse failures encountered while expanding autoinclude files during stack generate, find, and list are surfaced with the underlying HCL diagnostic instead of being swallowed or remapped to a generic discovery error.

Reported in #​5980.

cas — Local paths supported as stack component sources

CAS-backed stack generation now accepts a local filesystem path as the source of a consumer stack or unit block, in addition to a remote Git URL. Terragrunt copies the referenced directory into a temporary directory, computes a content-addressed root hash over the copy, and applies the same update_source_with_cas rewriting as the remote flow. The original directory is left untouched.

# live/terragrunt.stack.hcl
stack "service" {
  source = "../catalog//stacks/service"

  path = "service"
}

This makes a catalog usable against a local checkout under the same update_source_with_cas = true attributes that already work for Git URLs, which is helpful when iterating on a catalog before tagging a release.

See the CAS documentation and Explicit Stacks: Local catalog sources for details.

catalog-redesign — Units and stacks, scaffolded values, and key-binding cleanup

The redesigned terragrunt catalog TUI gains two new component kinds, a guided scaffolding flow for placing them, and a small key-binding cleanup.

Units and stacks join modules and templates

Catalog discovery now classifies units (directories containing a terragrunt.hcl) and stacks (directories containing a terragrunt.stack.hcl) as first-class component kinds, alongside OpenTofu/Terraform modules and boilerplate templates. The list view picks them up automatically and they appear under their own tabs; press tab and shift+tab to cycle.

When more than one classification could apply to the same directory (for example, a stack directory that also contains a unit), Terragrunt resolves it to a single kind under a fixed precedence: template, stack, unit, module.

Copy and scaffolded values

Selecting a unit or stack from the catalog now offers a copy action that materializes the component into your working directory. Terragrunt walks the copied component for values.<name> references and, if it finds any, writes a sibling terragrunt.values.hcl stub. Names referenced outside a try(...) are listed as required with a "TODO" placeholder; names referenced through a try(...) are listed as optional, pre-populated with the literal default from the fallback. An existing terragrunt.values.hcl is left alone.

After the TUI exits, Terragrunt prints a short callout pointing at the directory it wrote to and any follow-up command you need to run, instead of leaving you to find the new directory yourself.

Catalog key bindings

The ctrl+j binding on the catalog list has been removed in favor of enter alone for choosing a focused entry, and dropped from the navigation set used while filtering. The mini help footer is updated to match.

stack-dependencies - Separate filenames for unit vs stack autoincludes

Generated autoinclude files now use distinct filenames depending on the component kind, so tooling (LSP, read_terragrunt_config(), indexers) can identify a file's purpose from its name alone:

  • Unit-level autoincludes continue to be written as terragrunt.autoinclude.hcl.
  • Stack-level autoincludes (autoinclude blocks declared inside a stack { ... }) are now written as terragrunt.autoinclude.stack.hcl. The .stack.hcl suffix mirrors terragrunt.stack.hcl, matching the convention used elsewhere for stack files.
# terragrunt.stack.hcl
unit "app" {
  source = "../catalog/units/app"
  path   = "app"

  autoinclude {
    # Generated as: .terragrunt-stack/app/terragrunt.autoinclude.hcl
    dependency "vpc" { config_path = unit.vpc.path }
  }
}

stack "networking" {
  source = "../catalog/stacks/networking"
  path   = "networking"

  autoinclude {
    # Generated as: .terragrunt-stack/networking/terragrunt.autoinclude.stack.hcl
    dependency "shared" { config_path = unit.shared.path }
  }
}

This change implements the naming convention proposed in the Stack Dependencies RFC so configurations for units and stacks always live in files whose names clearly indicate their purpose.

To learn more, see the experiment documentation.

stack-dependencies — Nested stack paths and discovery integration

The stack-dependencies experiment gains two improvements: nested stack path references at arbitrary depth, and integration with the find and list discovery commands.

Nested stack path references

stack.<name>.<nested_stack>.path now resolves at arbitrary nesting depth. Previously, only units within a stack were reachable via stack.<name>.<unit_name>.path; nested stacks are now first-class references too.

# terragrunt.stack.hcl

stack "infra" {
  source = "../catalog/stacks/infra"
  path   = "infra"
}

unit "app" {
  source = "../catalog/units/app"
  path   = "app"

  autoinclude {
    dependency "deep" {
      # infra contains a nested "deep" stack; reference it directly.
      config_path = stack.infra.deep.path
    }

    inputs = {
      val = dependency.deep.outputs.val
    }
  }
}

Discovery commands surface stack dependencies

The terragrunt find and terragrunt list discovery commands now reflect stack dependencies generated by the autoinclude block. The DAG output correctly orders units by their autoinclude dependencies and shows dependency relationships in JSON, tree, and long formats.

# JSON output includes dependency relationships from autoinclude
$ terragrunt find --json --dag --dependencies --experiment stack-dependencies

# Long list format shows a Dependencies column
$ terragrunt list --long --dependencies --dag --experiment stack-dependencies

# Tree format visualizes the dependency hierarchy
$ terragrunt list --tree --dag --experiment stack-dependencies

Multi-level dependency trees (for example, A → B,C where B → D,E) are ordered correctly in DAG mode: leaf units appear first, parents appear after all their dependencies.

To learn more, see the experiment documentation.

Cache and plugin directories follow platform conventions

Terragrunt's global cache directory now resolves to the platform's user cache location instead of a hard-coded ~/.cache/terragrunt. On Linux this honors XDG_CACHE_HOME (still ~/.cache/terragrunt by default), on macOS it resolves to ~/Library/Caches/terragrunt, and on Windows it resolves under %LocalAppData%. The CAS content store, the auto provider cache, and the IaC engine plugin directory all move with it.

Existing caches at the previous locations are not migrated. They become orphaned and continue to consume disk space until removed.

Consider deleting the old paths to reclaim that space if you are on macOS or Windows, or have configured a custom XDG_CACHE_HOME:

# CAS store and engine plugins under the legacy ~/.cache layout
rm -rf ~/.cache/terragrunt

What's Changed

New Contributors

✂ Note

PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

  • Branch creation
    • "every weekend"
  • Automerge
    • At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

  • If you want to rebase/retry this PR, check this box

This PR has been generated by Mend Renovate.

@zon-renovate zon-renovate force-pushed the renovate/gruntwork-io-terragrunt-1.x branch from f354f6b to 6d4d897 Compare April 21, 2026 13:13
@zon-renovate zon-renovate changed the title chore(deps): update gruntwork-io/terragrunt to 1.0.1 chore(deps): update gruntwork-io/terragrunt to 1.0.2 Apr 21, 2026
@zon-renovate zon-renovate force-pushed the renovate/gruntwork-io-terragrunt-1.x branch from 6d4d897 to f2d6ad1 Compare April 27, 2026 15:13
@zon-renovate zon-renovate changed the title chore(deps): update gruntwork-io/terragrunt to 1.0.2 chore(deps): update gruntwork-io/terragrunt to 1.0.3 Apr 27, 2026
@zon-renovate zon-renovate changed the title chore(deps): update gruntwork-io/terragrunt to 1.0.3 chore(deps): update gruntwork-io/terragrunt to 1.0.4 May 7, 2026
@zon-renovate zon-renovate force-pushed the renovate/gruntwork-io-terragrunt-1.x branch 2 times, most recently from 04cee67 to 95a4890 Compare May 11, 2026 14:13
@zon-renovate zon-renovate force-pushed the renovate/gruntwork-io-terragrunt-1.x branch from 95a4890 to f21029e Compare May 18, 2026 17:15
@zon-renovate zon-renovate changed the title chore(deps): update gruntwork-io/terragrunt to 1.0.4 chore(deps): update gruntwork-io/terragrunt to 1.0.5 May 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

dependencies tool-binaries

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@zon-renovate