-
Notifications
You must be signed in to change notification settings - Fork 113
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
Adding ApplyJSON(), DestroyJSON(), PlanJSON() and RefreshJSON() functions #354
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good to me although I would prefer to hear an opinion from @radeksimko / @kmoe 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Aside from my mostly minor in-line comments I have three higher-level questions:
- Can you confirm the assumption that with JSON output, the error matching does not work as expected (i.e. we produce generic error types, rather than the ones from https://github.com/hashicorp/terraform-exec/blob/main/tfexec/errors.go )? It's fine if it doesn't - that is one of the reasons we wanted to make it a separate method, but it would be great to have that theory confirmed + more importantly have it documented - ideally both in the comment above the method and in the Changelog. We should have an answer for those who'd rightly be confused about the similar methods.
- The other reason (in addition to ^) we wanted to make separate
*JSON
methods is that all methods should work with JSON by default. I'm assuming the (in)stability is already communicated through the0.x.x
version, but is it worth mentioning the (likely) future of these methods in the comment? i.e. that they're most likely to be removed in the future major version in favour of Apply/Refresh/Destroy? - Have you tried using this API without buffering? I'm guessing it should work just fine with the help of
io.Pipe
? Just trying to get an answer for @thrashr888 in Plan/Apply-json
support missing #183 who I believe might want to avoid buffering.
Thank you for adding all the tests. I'm assuming the 3 failures are related to the upstream hc-install
bug, which is something I'm working on, so you can ignore these for now.
Co-authored-by: Radek Simko <[email protected]>
… in terraform command (#353)
… removed in the future (#353)
With the We're using code such as the following in terraform-plugin-testing to detect such errors: if err != nil {
target := &tfexec.ErrVersionMismatch{}
if errors.As(err, &target) {
... See https://github.com/hashicorp/terraform-plugin-testing/pull/17/files#diff-fb41773504c4caa3fef8e2f58c5839a3959cac7c99ad150aca6acf8e1d276bb0R188 for an example implementation. @radeksimko given the original errors are preserved can you confirm that the documentation and changelog do not need altering?
I have updated the Go docs for
I have tested the API without buffering (i.e., using io.Pipe). The following test produces the output below: func TestApplyJSONCmdPipe(t *testing.T) {
td := t.TempDir()
tf, err := NewTerraform(td, tfVersion(t, testutil.Latest_v1))
if err != nil {
t.Fatal(err)
}
// empty env, to avoid environ mismatch in testing
tf.SetEnv(map[string]string{})
pipeReader, pipeWriter := io.Pipe()
defer pipeWriter.Close()
go func() {
defer pipeReader.Close()
if _, err := io.Copy(os.Stdout, pipeReader); err != nil {
log.Fatal(err)
}
}()
err = tf.ApplyJSON(context.Background(), pipeWriter)
if err == nil {
t.Fatal("error expected, got nil")
}
}
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
given the original errors are preserved can you confirm that the documentation and changelog do not need altering?
Yep, we're good on that front.
Thank you for making the changes. LGTM
Closes: #353