Use "--terragrunt-quiet" as the first argument to suppress that.

https://terragrunt.gruntwork.io/docs/reference/built-in-functions/#run_cmd

How do I add that flag to terragrunt in pipelines?

Also having the command output in debug logs is useful, and that flag redacts the command output from the debug logs.

You put it in the HCL for run_cmd.

You can write to stderr from run_cmd and it won't be forwarded to HCL attributes or captured on plans, etc.

Hold up, this is intended behavior!? What possible process or problem is solved by interleaving the output of a command (whose output is returned as a value) with terragrunt's other output? It doesn't even get the prefix + formatting treatment like the rest of terragrunt's output does.

Fwiw I agree that having raw stdout instead of the wrapped "INFO terraform:" stdout treatment feels inconsistent.

In normal circumstances I would expect subshelled processes to log to a parent process logger.

Fwiw I agree that having raw stdout instead of the wrapped "INFO terraform:" stdout treatment feels inconsistent.

In normal circumstances I would expect subshelled processes to log to a parent process logger.

It does also do this, though only in debug logs.

@ThisGuyCodes @odgrim

I totally agree that it would have been better design to start with, but this is an old HCL function, and removing the need to use "--terragrunt-quiet" as the first argument to run_cmd to get (what all three of us likely believe to be) optimal behavior is a breaking change.

We try really hard to avoid breaking changes, especially in HCL configurations, as it's a lot harder to have people to change those than CLI arguments.

What we've considered doing is simply introducing a new HCL function with better defaults and deprecating run_cmd. Something like exec, where you opt-in to debug logging. Something like:

locals {
  value = exec("echo", "hello")
  debugged_value = exec("--tg-x-debug", "echo", "hello")
}

Where the call to populate value won't trigger debug logging, and debugged_value will.

The time it makes the most sense to start talking about this kind of thing is next week, when we release experimental support for the new exec and run commands. Which are being added as part of the CLI Redesign.

In the interim, I recommend that you just consider the default way to use run_cmd the following:

run_cmd("--terragrunt-quiet", ...)

That's what I do.

Oh you give the --terragrunt-quiet to run_cmd? That's a bit - unintuitive, but definitely flexible! (Does HCL support key word arguments for functions?

I do want to distinguish the concept of "debug logging" from "interleaving output" though. Currently, terragrunt will also include the output of the command in its debug logs, but with this quiet flag it will suppress the debug logs as well.

I understand not interleaving output would be a breaking change (though I would argue that "breaking changes" to the stdout have been made before. Much more significant ones at that.)

@ThisGuyCodes

We really do try to to minimize them 😁

We generally only introduce breaking changes to Terragrunt terminal output if there's a significant change to the QoL of Terragrunt users that is infeasible otherwise. We're also trying to get better about giving users a way to gradually adopt breaking changes, rather than doing it all at once with Strict Mode.

HCL functions end up calling Golang functions, so we can customize the logic for any Terragrunt-native HCL function however we like (within reason)! The only functions we don't have that level of control over are OpenTofu/Terraform-native HCL functions, as we pull those in via a pinned dependency on an old version of Terraform (for now, at least).

Giving flags to the run_cmd function is convenient because it allows multiple run_cmd calls in the same unit to behave differently. That part of the design, I like.

I recommend adding debug logs to the run_cmd function using stderr when necessary.

e.g.

#!/usr/bin/env bash

>&2 echo "DEBUG: run_cmd - This won't write to stdout, and won't be pulled into the attribute run_cmd is assigned to!"

I understand wanting to avoid breaking changes.

One disconnect I want to clear up: it seems you keep referring to "output on run" as "debug logging", whereas when I have been saying "debug logging" I've been referring to the debug logger, such as here: https://github.com/gruntwork-io/terragrunt/blob/main/config%2Fconfig_helpers.go#L387

Using the proper logger allows folks to enable or disable debug logging at invocation without needing to change source code. However, the way the code is currently written, I cannot suppress this output which is breaking my pipelines without also suppressing the output in debug logs.

For what it's worth I'm a huge fan of mechanisms like your strict mode to introduce breaking changes! Makes me think of things like from __future__ in Python, which I'm also a big fan of

I get where you're coming from, @ThisGuyCodes .

To be clear, I think it would be better design for run_cmd to:

1. Write nothing to terminal stdout/stderr when used by default.
2. Write stdout to the DEBUG log level when --terragrunt-log-level (soon to be --log-level) is set to debug, so that users can debug run_cmd invocations without changing HCL.
3. Write stdout to the INFO log level when users opt in to have the function do that via an HCL flag as the first argument.
4. Write stderr to the ERROR log level.

I think that would be a smoother and more flexible design.

We'll look to implement something like that in the future for a different HCL function like exec, which gives us the opportunity to avoid introducing any breaking changes to terminal output for existing HCL functions.

For the sake of Pipelines, you can suppress output while debugging, as I understand it. If you use a combination of --terragrunt-quiet and writing to stderr in your scripts, you'll be able to log to GitHub Actions logs, and it won't interfere with GitHub comments, or population of HCL attributes in locals, etc.

I've checked a bunch of releases and it looks like the version v0.46.0 is affected, but v0.45.18 is not.