fix: MarshalYAML receivers on TLSVersion and Curve#288
Conversation
|
Seems like we should have tests for this behavior. |
|
Cheers @SuperQ !! Currently there are no unit tests that generates YAML files from Go structs. Happy to add few unit tests for this use case. |
|
Yes, if you could add some tests, that would be very useful. |
|
@SuperQ Added few unit tests and updated PR description |
|
Do you have any plans to merge this? We are also looking for this fix. |
|
Can you rebase this? Thanks! |
* Currently the `MarshalYAML` receivers are defined on pointers of `TLSVersion` and `Curve` but `TLSConfig` is defined with values of `TLSVersion` and `Curve` in its fields. So, `MarshalYAML` receiver is never called upon. This commit fixes it by changing receivers on values which should work on both values and pointers. Signed-off-by: Mahendra Paipuri <44365948+mahendrapaipuri@users.noreply.github.com>
Signed-off-by: Mahendra Paipuri <44365948+mahendrapaipuri@users.noreply.github.com>
* Add omitempty tags to all fields in the config to avoid rendering zero values in generated config Signed-off-by: Mahendra Paipuri <mahendra.paipuri@gmail.com>
323787d to
a0ec107
Compare
|
@roidelapluie Should be good now!! |
| HTTPConfig HTTPConfig `yaml:"http_server_config"` | ||
| RateLimiterConfig RateLimiterConfig `yaml:"rate_limit"` | ||
| Users map[string]config_util.Secret `yaml:"basic_auth_users"` | ||
| TLSConfig TLSConfig `yaml:"tls_server_config,omitempty"` |
There was a problem hiding this comment.
Please remove all the omitempty and let's have this in another PR where we can discuss which ones are valuable and which one are not wanted.
There was a problem hiding this comment.
Well, without omitempty, the marshalling config structs can produce "invalid" config files which is not desired I assume. For instance, if we do not set min_version or max_version in config struct, withot omitempty, the config file will contain min_version: "0" which is not valid.
There was a problem hiding this comment.
Yes it depends on the fields, but some of them are really off. I do think we would want to discuss this separately
| }, | ||
| } | ||
|
|
||
| for _, test := range testTables { |
There was a problem hiding this comment.
Please use t.Fatalf and subtests
There was a problem hiding this comment.
Ok, will do that! Cheers!
| } | ||
| } | ||
|
|
||
| func TestConfigGeneration(t *testing.T) { |
There was a problem hiding this comment.
Maybe we can have narrower tests as wel.
Additionally, this test could test the round trip as well.
There was a problem hiding this comment.
Could you please elaborate on narrower tests? What exactly do you see? Cheers!
There was a problem hiding this comment.
testing marshal/unmarshal on curve directly as well
roidelapluie
left a comment
There was a problem hiding this comment.
(removing approval mark for now)
Currently the
MarshalYAMLreceivers are defined on pointers ofTLSVersionandCurvebutTLSConfigis defined with values ofTLSVersionandCurvein its fields. So,MarshalYAMLreceiver is never called upon. This commit fixes it by changing receivers to non-pointer values which should work on both values and pointers.Reproducer that shows the behaviour:
This should produce an output as follows:
With current package's implementation,
yaml.Marshalproducesuintformin_version,max_versionandcurve_preferneces. When changed to receivers ofMarshalYAMLto non-pointer values, marshalled config produces correct output.This PR fixes the marshall receivers and add unit tests to verify config file generation from structs.
omitemptyhas been added to the config fields to avoid producing "zero" values when config file is being generated from Go structs. When fields are not set, the library use "sane" defaults which can be leveraged by client libraries.