You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Is your feature request related to a problem? Please describe.
It is possible for structs to contain fields that cannot be marshaled into YAML. We recently went through the process of updating or removing some of these (e.g. #10310), but there are currently no tests in place to ensure non-marshalable fields will be added in the future.
In particular, I want do so something like this:
// Programmatically-generated configcfg:= otelcol.Config{...}
// Should marshal to YAMLconf:=confmap.New()
conf.Marshal(cfg)
// Should be equivalent to cfgcfg2:=unmarshal(conf)
Describe the solution you'd like
Add tests to mdatagen that test that we can marshal/unmarshal all config structs. Ideally, we put the config structs through an iteration of marshaling and unmarshaling to ensure the structs can't easily enter a state where conversion is impossible.
Describe alternatives you've considered
Some kind of integration test that happens in a secondary package could be a possible way to do this, and would forgo the need for a direct confmap dependency in every package that for use only in tests.
The text was updated successfully, but these errors were encountered:
This updates the generated config types to be created with go-jsonschema
v0.17.0, which includes an update to add a struct tag the
`AdditionalProperties` field that allows it to be marshaled.
Making this change fixes the following error that occurs when I marshal
a basic `otelcol.Config` struct, then run it with the Collector:
```
'metrics.readers[0].pull.exporter' has invalid keys: additionalproperties
```
Related to
open-telemetry/opentelemetry-collector#11711.
Is your feature request related to a problem? Please describe.
It is possible for structs to contain fields that cannot be marshaled into YAML. We recently went through the process of updating or removing some of these (e.g. #10310), but there are currently no tests in place to ensure non-marshalable fields will be added in the future.
In particular, I want do so something like this:
Describe the solution you'd like
Add tests to mdatagen that test that we can marshal/unmarshal all config structs. Ideally, we put the config structs through an iteration of marshaling and unmarshaling to ensure the structs can't easily enter a state where conversion is impossible.
Describe alternatives you've considered
Some kind of integration test that happens in a secondary package could be a possible way to do this, and would forgo the need for a direct
confmap
dependency in every package that for use only in tests.The text was updated successfully, but these errors were encountered: