feat: Add flag to strip refresh output from errored plans

[patrickvinograd]

what

• Adds a server config flag "strip-refresh-output-from-errors"
• If true, strips the "Refreshing state..." lines from plan error output, as it does for successful plan output.

why

• With large states, any error during planning results in a flurry of Github comments (and in our case, slack messages) containing all the "Refreshing state..." messages. We find these are rarely any help in resolving the plan error.

• But, some people may want the full output, so make it a configurable flag to allow choice in the matter.

• I considered making this the default and controlling it with the Verbose flag, but wasn't sure if overriding that flag's semantics was wise.

• I also considered returning the full vs. stripped output in the result object, and allowing users to customize what gets rendered via templates/template overrides. But this might involve changes to existing templates/variables and thus break people's overrides in the wild.

tests

• Added a unit test in plan_step_runner_test.go

references

• refreshing output not stripped in error output with 'strip_refreshing' on custom run command #4442 made a change to strip refresh output from custom command errors, but that behavior is under the control of the strip_refresh parameter on individual custom commands.

[jamengual]

hi @patrickvinograd can you just do this creating your own templates?

[patrickvinograd]

hi @patrickvinograd can you just do this creating your own templates?

Possibly, I mentioned that option in the PR comment. But as of now wrappedErr.tmpl just renders .Error. I would need to plumb the stripped version of the terraform output through command.ProjectResult to make it available as a template variable. Then do I also include the full output and the stripped output, plus it's kind of duplicative of ProjectResult.PlanSuccess.TerraformOutput, but that's not even set on an error. Enough uncertainty there that I opted to keep the stripping logic in the plan_step_runner, just controlled by a config flag.

I do agree there's already a ton of config flags and templates are a nice solution. Happy to re-work, I just would appreciate some guidance about where in ProjectResult it would be best to plumb these result variations through.

[jamengual]

I will ask @lukemassa @chenrui333 to chime in.
I will say that extending the templates will be better since that will allow further trimming as needed.