v0.14.7

Added

• Add support for most recent Terragrunt versions. Terramate will now detect the installed Terragrunt version and set internal commandline flags accordingly.

Fixed

• Apply --include-output-dependencies and --only-output-dependencies flags when used together with --no-recursive.
• Change the output buffering behaviour of run and script run to allow the use of interactive prompts
  (e.g. terraform apply) that wait for input in the same line.
  • Fix a regression for this specific use-case, which was introduced in 0.14.4, where all output was buffered by line.
  • Only supported when running (1) not in parallel and (2) not syncing to Terramate Cloud.
    Otherwise, the output will be buffered by line to avoid issues.
• Fix handling of null values for tm_slug(). They will now be passed through, so tm_slug(null) -> null.

v0.14.6

Added

• Add more filter flags for trigger and debug show {metadata,globals,generate-origins,runtime-env} commands.
  Some flags were already listed in the help, but ignored by the command. The following flags work as intended now:
  • --status
  • --drift-status
  • --deployment-status
  • --tags
  • --no-tags

v0.14.5

Added

• Add tm_unslug() function: New stdlib function that maps slugs back to their original human-readable strings using a provided dictionary. Supports both string and list(string) inputs, with the output shape mirroring the input. Features include:

  • Dictionary-based reverse mapping for reliable unslugging
  • Normalization of input slugs (lowercase, collapsed separators, trailing separator removal)
  • Collision detection with typed error (UnslugErrorIndeterministic)
  • Round-trip guarantee: tm_unslug(tm_slug(word), dictionary) == word for all words in dictionary
  • Extensive special character support (Unicode, emoji, punctuation, etc.)

• Add tm_slug() function: New stdlib function that converts strings to URL-safe slugs. Accepts both string and list(string) inputs, returning the appropriately typed slugified result. Properly handles null values in list or tuple elements without panics.

  tm_slug("Hello World!")
  # Returns: "hello-world"
  
  tm_slug(["Feature/Branch", "Bug Fix", "Release 2.0"])
  # Returns: ["feature-branch", "bug-fix", "release-2-0"]

• Add tm_joinlist() function for joining nested lists of strings with a separator.

  tm_joinlist("/", [["root"], ["root", "child"], ["root", "child", "leaf"]])
  # Returns: ["root", "root/child", "root/child/leaf"]

• Add tm_tree() function for constructing hierarchical paths from parent-child relationships.

  tm_tree([[null, "root"], ["root", "child1"], ["root", "child2"], ["child1", "leaf"]])
  # Returns: [["root"], ["root", "child1"], ["root", "child1", "leaf"], ["root", "child2"]]

• Add support for slashes (/) in tags.

v0.14.4

Fixed

• Fix ANSI escape codes that are printed to the console when running terragrunt commands with the --parallel flag.

v0.14.4-rc1

Fixed

• Fix ANSI escape codes that are printed to the console when running terragrunt commands with the --parallel flag.

v0.14.3

Added

• Add option --plan-render-timeout to run, and the corresponding script command option plan_render_timeout.
  • This configures the maximum time to wait (in seconds) for rendering change summaries from plan files, which will be sent to Terramate Cloud.
  • The previous default value was hardcoded at 300 seconds. In most scenarios this is more than enough,
    but there have been reported cases where rendering the changes took longer.
  • Exceeding the timeout will skip sending the change summaries, but the command status and logs are still sent.

v0.14.2

Fixed

• Fix crash in the terramate cloud login --sso command.

v0.14.1

Fixed

• Fix crash in the terramate install-completions command.
• Fix error on duplicate Terragrunt dependencies in create --all-terragrunt.
  • Duplicates are now removed and the command will no longer fail.
• Fix mistakenly detecting stacks as changed on changes in referenced Terraform modules.
  • A change in a module that is referenced by stack-a would also mark stack-aa as changed (and other stacks with a common name prefix).

v0.14.0

Fixed

• BREAKING CHANGE Massively improve stack order evaluation performance.

  This affects and improves commands that use the stack order, i.e. run, run script, list --run-order.
  As a consequence, the evaluation order of unrelated stacks may change.

  • Example 1:
    Nested stacks a must be executed after their parent stacks, but /stack1 and /stack2 are independent.

    Old run order:

    /stack1
    /stack1/a
    /stack2
    /stack2/a
    

    New run order:

    /stack1
    /stack2
    /stack1/a
    /stack2/a
    

  • Example 2:
    stack2 must be executed after stack1, but stack1 and stack3 are independent in the follwing configuration:

    /stack1 
    /stack2 (after=[stack1])
    /stack3
    

    Old run order:

    /stack1
    /stack2
    /stack3
    

    New run order:

    /stack1
    /stack3
    /stack2
    

  The new rule recursively aligns stacks that are independent into groups.

  • The first group contains all initially independent stacks.
  • The second group contains all stacks that just depended on stacks in the first group.
  • The third group contains all stacks that just depended on stacks in both previous groups.
  • The fourth group and following groups continue in the same way.

  Stacks in each group are ordered lexicographically and returned as the order of execution when running sequentially.

  The run order when using the --parallel flag is not affected by this change.

v0.14.0-rc1

Fixed

• (BREAKING CHANGE) Improve stack order evaluation performance.
  This affects commands that use the stack order, i.e. run, run script, list --run-order.
  As a consequence, the evaluation order of unrelated stacks may change.

  • Example 1

    /stack1
    /stack1/a
    /stack2
    /stack2/a
    

    Sub-stacks a must be executed after their parent stacks, but /stack1 and /stack2 are unrelated.

    Old run order:

      /stack1
      /stack1/a
      /stack2
      /stack2/a
    

    New run order:

      /stack1
      /stack2
      /stack1/a
      /stack2/a
    

  • Example 2

    /stack1 
    /stack2 (after=[stack1])
    /stack3
    

    stack2 must be executed after stack1, but stack3 is unrelated.

    Old run order:

      /stack1
      /stack2
      /stack3
    

    New run order:

      /stack1
      /stack3
      /stack2
    

  The new rule first runs stacks that have no dependencies in group 1,
  then those in group 2 that depend on stacks in group 1,
  then those in group 3 that depend on stacks in group 1 and group 2, and so on.
  Stacks in each group are ordered lexicographically.

  The run order when using the --parallel flag is not affected by this.