hashicorp / hashicorp/terraform-exec
Consider including stderr in error from Init
- Dominant language
- Go
- Stars
- 786
- Forks
- 129
- PR merge metrics
- No merged PRs in 30d
Description
One of the nightly E2E tests had failed with the following output:
```
=== RUN TestDestroy/basic-0.12.30
util_test.go:110: [INFO] running Terraform command: /var/folders/6y/gy9gggt14379c_k39vwb50lc0000gn/T/tfinstall342488260/v-0.12.30/terraform init -no-color -force-copy -input=false -lock-timeout=0s -backend=true -get=true -upgrade=false -lock=true -get-plugins=true -verify-plugins=true
destroy_test.go:16: error running Init in test directory: exit status 2
2021/04/05 00:22:07 [DEBUG] Using modified User-Agent: Terraform/0.12.30 tfexec-e2etest HashiCorp-terraform-exec/0.13.1
```
Here `exit status 2` is not enough context for further debugging - which is "fine" if it's just a nightly test (although annoying), but it may not be that great for a consumer leveraging `Init()` and needing to debug similar error.
which makes me wonder if it's worth either:
1. Including stderr in the error at all times (for commands that otherwise don't expose stderr), or
2. Revisiting the idea of custom error types, which was initially binned due to worries about breaking compatibility when exploring ways of resolving https://github.com/hashicorp/terraform-exec/issues/107
Contributor guide
Research direction
Start by examining the Init() error path and how command stderr is currently handled, then review the compatibility concerns in issue #107. Determine whether actionable stderr or custom error types best addresses the reported exit-status-only failure, and add focused coverage for the chosen behavior.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go, terraform
- Domain
- cli
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 35/100