Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix error output in plan-all.. #789

Closed
wants to merge 4 commits into from
Closed

Conversation

mariux
Copy link

@mariux mariux commented Jul 21, 2019

tries to fix issues mentioned in #397:

when runnign plan-all every run states "Errors with plan".. which is due to capturing wrong output.
This patch series fixes several issues and add minor improvements in output:

  • fix wrongly detected error by not capturing output for non terraform commands
  • fix wrongly captured output for "init-from-module" pseudo-command run
  • improve plan-all error output by adding module path of captured error
  • improve plan-all output by displaying errors while happening and repeating them in final summary.

it's my first go code ;) so feel free to just take it as a hint how this was fixed for me.

Copy link
Member

@brikis98 brikis98 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR!

fix wrongly detected error by not capturing output for non terraform commands
fix wrongly captured output for "init-from-module" pseudo-command run

Can you explain what you mean by these? Perhaps with an example?

@@ -95,6 +95,7 @@ func downloadTerraformSourceIfNecessary(terraformSource *TerraformSource, terrag
// before and after hooks (if any).
terragruntOptionsForDownload := terragruntOptions.Clone(terragruntOptions.TerragruntConfigPath)
terragruntOptionsForDownload.TerraformCommand = CMD_INIT_FROM_MODULE
terragruntOptionsForDownload.Logger = terragruntOptions.Logger
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does Clone not do this automatically?

Copy link
Author

@mariux mariux Jul 24, 2019

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

the clone function sets up a new logger logging to the current ErrWriter.. which is not where the current logger is logging to..

I know this might not be the cleanest solution to just set it this way, but since it fixed it for me, i went for it.

maybe an actual go developer can come up with a cleaner implementation ;)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

btw it seems that ErrWriter and Logger are not really connected in a logical consequent way. since setting ErrWriter does not change the Logger in any way and also not sets up a new Logger.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hm, it seems like the right fix would be to make the Clone method do the right thing. This small workaround means (a) that Clone may still be doing the wrong thing in other places and (b) if we make updates to Clone in the future, that may break in this one-off fix here.

}

if terragruntOptions.ErrWriter != os.Stderr {
errWriter = io.MultiWriter(terragruntOptions.ErrWriter, os.Stderr)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you explain the thinking behind these changes a bit more?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is basically taking care of giving a summary of all errors at the end of a plan-all run and printing the errors while running... the check is needed to not print logs twice while running if used in a normal plan (run without being wrapped in a plan-all)..

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is the RunShellCommandWithOutput method, which is used in many places in the code base, and not just during plan-all commands. I'm a little concerned about piling up workarounds within RunShellCommandWithOutput that are intended for other methods, as it's not at all obvious why this would be here from just reading this part of the code. Is there some other way to set terragruntOptions params correctly so this method does the right thing without one-off hacks?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

agreed.. ;) i can try to fix it in another way..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

as far as i have seen ErrWriter is not used in a consequent manner and fixing it in a nicer way would require a lot of refactoring as there are already a lot of exceptions throughout the code..

@mariux
Copy link
Author

mariux commented Jul 24, 2019

Can you explain what you mean by these? Perhaps with an example?

fix wrongly captured output for "init-from-module" pseudo-command run

this is basically a fix to the issue described in #397: where at the end of a plan-all run all errors are printed by basically just capturing everything sent to stderr and postponing the output to the end of the plan-all phase.
since this "all errors from plan" should just include errors from actually running a terraform plan and not (as it does at the moment) also stuff printed to stderr by terragrunt (e.g. in the "init-from-module" phase or from setting up the s3-backend).

fix wrongly detected error by not capturing output for non terraform commands

what also got wrongly captured was stderr from hooks: e.g. from running a cp -v ....
which does not make sense because hooks have their own error handling so also the output does not need to be postponed...

@brikis98
Copy link
Member

How does your fix compare to #722?

@mariux
Copy link
Author

mariux commented Jul 25, 2019

How does your fix compare to #722?

good question... basically this code adds fixes for already intended functionality without adding more complexity.. but feel free to close this one if the other PR also improves it.. i guess the outcome is very similar..

@mariux mariux closed this Jul 2, 2020
@mariux
Copy link
Author

mariux commented Jul 2, 2020

closed as this is outdated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants