config: add json tags to config structs
This adds json tags to config struct fields. This is needed for us to reuse the structs in an internal kubernetes operator.
If just adding the tags is unwanted, I can also look into adding general support for json configs. We would need to add UnmarshalJSON functions like the UnmarshalYAML functions.
Used SED to add the json tags.
sed -i 's/`\(yaml:"\(.*\)"\)`/`\1 json:"\2"`/g' config/config.go
Closes #1308
If just adding the tags is unwanted, I can also look into adding general support for json configs. We would need to add UnmarshalJSON functions like the UnmarshalYAML functions.
thank you for sending this in, just tags are okay.
I am not sure if we want to add support for json configs, I don't see a big reason to add support for json configs.
thank you for sending this in, just tags are okay.
Perfect, thank you.
Just adding the json tags won't work as it also needs custom Unmarshal functions. As the json support is not wanted? I might close the PR and do the changes in my fork :/ (Currently still working on the custom Unmarshal functions. Once it is done I would open an PR and you can decide if you want it or not?)
also needs custom Unmarshal functions
we don't mind having the JSON Unmarshal functions, it would be useful to folks using Blackbox exporter as a library and build on top of Blackbox exporter like you are doing
What I meant was the full fledged support for configuring blackbox exporter via a json config file instead of YAML, in that side, will stick with YAML only.
First step is done with the custom Unmarshal functions. I might need to add some Marshal functions as well.
Can already tell that the current json lib is a pain as it does not support inline fields.
If wished I can also generate the json test cases during the test by converting the original yml test case to a json file. Would remove the "duplicate" test data.
If wished I can also generate the json test cases during the test by converting the original yml test case to a json file. Would remove the "duplicate" test data.
yes, that would be better then the duplicate config files.
As an additional question. Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted. From what I know right now, there is no nice way to Marshal the config. To solve this we could make all the Modules pointers that would get omitted.
Is it intended that the Config should not be Marshaled? Asking because when marshaling the Config all the Default values of the other modules are printed as well and are not omitted.
I don't think we thought about this before, this might be the default. changing the way config is Marshaled would need a little more discussion.
if you want to change that marshaled, I would recommend creating an issue to discuss this with everyone, and if we agree on changing, i would prefer it to be it's own PR.
@Jakob3xD checking in on this PR, we would be open to merge this if you can update and rebase it.
@Jakob3xD following up on this, I am open to merge this if this can be rebased and updated to include changes from master. 🙏🏼
@electron0zero sorry for the late response. I´ll try to have a look at this in the next week to get this done.