plan-all buffers terraform stderr

[andysworkshop]

The current implementation of plan-all buffers all stderr output from every terraform invocation in order to parse it for a specific error case.

This is fine for 'normal' runs but unfortunately when TF_LOG is set to debug then the provider's logging appears on stderr. This results in several problems for terragrunt:

• The provider output appears out of context. We don't know which terraform invocation is producing it because it's all dumped nose-to-tail at the end.
• The azure provider in particular produces megabytes of logging. We have up to 100 terraform invocations. Buffering all this causes terragrunt.exe to consume over 1Gb of memory.
• The above memory usage was causing our node to kill the container running terragrunt. This resulted in no provider logging at all because terragrunt was killed before it could get to the parse/dump stage.

Would anyone object to a PR that made capturing stderr conditional on TF_LOG being unset? I think it's reasonable to assume that if TF_LOG has been set then you've got developers debugging and the buffering/parsing logic isn't required.

[yorinasub17]

I am not sure a feature to buffer stderr conditional on TF_LOG is the right approach here.

A better approach would be to use a goroutine to check the error stream line by line incrementally instead of buffering and checking at the end.

[andysworkshop]

I am not sure a feature to buffer stderr conditional on TF_LOG is the right approach here.

A better approach would be to use a goroutine to check the error stream line by line incrementally instead of buffering and checking at the end.

That could work, and would be a better approach if it does. I'll see what I can do.

[duxbuse]

A better approach would be to use a goroutine to check the error stream line by line incrementally instead of buffering and checking at the end.

I am also having issues where with large repositories to run it all in parallel ends up using multiple gigs of memory breaking my github actions. Which means I can't run it in parallel so it takes a long time to run.