-
Notifications
You must be signed in to change notification settings - Fork 232
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
Support testing of configurations in JSON syntax. #722
Support testing of configurations in JSON syntax. #722
Conversation
Thank you for your submission! We require that all contributors sign our Contributor License Agreement ("CLA") before we can accept the contribution. Read and sign the agreement Learn more about why HashiCorp requires a CLA and what the CLA includes 0 out of 2 committers have signed the CLA.
Have you signed the CLA already but the status is still pending? Recheck it. |
Hi @rudo-thomas 👋 Thank you for raising this, it is a nice enhancement. I'm curious if instead of requiring an additional and explicit configuration option, if this could instead be automatically determined by the content being passed through (Aside: Please note that the maintainers handle updating the |
This implements the proposal described at hashicorp#722 (comment)
47857b0
to
57804fc
Compare
Thanks @bflad , your suggestion makes perfect sense: Automatic detection is much easier to use, there is no ambiguity (a HCL config cannot be valid JSON and vice-versa), and the implementation is cleaner too :) I've re-worked and re-based this PR. PTAL |
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.
Overall this is looking pretty good! Just some minor refactoring and I think this will be good to go.
func (wd *WorkingDir) configFilename() string { | ||
return filepath.Join(wd.baseDir, ConfigFileName) | ||
} |
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.
For consistency, I think we should still keep this method around to automatically do the file joining:
func (wd *WorkingDir) configFilename() string {
return filepath.Join(wd.baseDir, wd.configFilename)
}
And set without baseDir via:
if json.Valid(bCfg) {
wd.configFilename = ConfigFileNameJSON
} else {
wd.configFilename = ConfigFileName
}
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.
Unlike WorkingDir.planFilename() -- which is "static" in the sense that it only depends on the Workdir.baseDir, configFilename is now "dynamic". It can be empty (SetConfig() not called yet) or one of the two cases (HCL/JSON).
When I tried your suggestion, configFilename() would:
- either have to return (string, error) (error in case no filename has been set up yet), or the caller would be responsible,
- or the caller would be responsible to check the filename field for emptiness.
The first option is of course the clean and correct one, but it felt cumbersome at the only place where this would be called (Init(), see below).
If you feel strongly, I can refactor it to the method that returns (string, error).
@@ -135,17 +153,13 @@ func (wd *WorkingDir) ClearPlan() error { | |||
// Init runs "terraform init" for the given working directory, forcing Terraform | |||
// to use the current version of the plugin under test. | |||
func (wd *WorkingDir) Init() error { | |||
if _, err := os.Stat(wd.configFilename()); err != nil { | |||
if wd.configFilename == "" { |
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.
The original os.Stat() is likely safer here, in case configFilename isn't reset to "". 👍
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.
Based on the error message, I feel like the original os.Stat() is here as a test whether SetConfig has ever been called.
I re-added the call to os.Stat().
internal/plugintest/working_dir.go
Outdated
if wd.configFilename != "" { | ||
err := os.Remove(wd.configFilename) | ||
if err != nil && !os.IsNotExist(err) { | ||
return err | ||
} | ||
} |
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.
Rather than checking for the filename, we should unilaterally remove/overwrite both the HCL and JSON configuration files here, just to prevent any potential oddities. If we want to be slightly more efficient, it can be done based on the json.Valid()
conditional below 👍
if json.Valid(bCfg) {
wd.configFilename = ConfigFileNameJSON
if err := os.Remove(filepath.Join(wd.baseDir, ConfigFileName)); err != nil && !errors.Is(err, fs.ErrNotExist) {
return fmt.Errorf("unable to remove %q: %w", ConfigFileName, err)
}
} else {
wd.configFilename = ConfigFileName
if err := os.Remove(filepath.Join(wd.baseDir, ConfigFileNameJSON)); err != nil && !errors.Is(err, fs.ErrNotExist) {
return fmt.Errorf("unable to remove %q: %w", ConfigFileNameJSON, err)
}
}
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 implements the proposal described at hashicorp#722 (comment)
57804fc
to
ec18310
Compare
This implements the proposal described at hashicorp#722 (comment)
ec18310
to
fdb3d4f
Compare
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.
Looks good to me, thank you for the updates and tests, @rudo-thomas 🚀
I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. |
This implements the proposal described in #721
The exported plugintest.WorkingDir.SetConfig API was deliberately left unmodified to avoid a breaking change.
The only possible breaking change is the mid-struct addition of the
ConfigIsJSON
field toTestStep
which could break users that initialise the structure without using the the Field: syntax. Such uses are very unlikely, as the structure had 19 fields already, 20 with this change.I wasn't able to find a good place to add tests for the new functionality. I'll be happy to take any advice on this. Thanks.