writeout: support to generate JSON output #4870
Conversation
|
The Linter is failing btw. The comma should be a point to be valid json. Also I personally would prefer to format the JSON human readable (with indents and newlines) but this is more of a non blocking issue |
|
Nevermind, looks like that's because of my shell |
|
yes, the "," originates from your environment BUT .. the feature should be a bit more robust coz the goal is to produce valid JSON. its different for the regular "-w" output coz there you get "text". |
|
We would also need a test or two added that verify that this actually does it is supposed to do! |
|
I would welcome it, but the decision is really @mgumz's to make... |
|
I'm not sure if I'll master it to write a test. I don't know how to verify dynamic variables such as |
Right, they are tricky. One way to test those things is to:
We have a bunch of tests working like this already. |
Or if there is a CURL struct which is actually filled with pseudo data and this struct is fed into the writeoutJSON function … then the only thing required is to actually provide a *FILE which ends up in a string which is then compared against the expected value. |
|
I've created an initial take at a test case for this functionality, sitting in my writeout-json-test branch. |
|
The red CI jobs seem to be unrelated. |
|
The reason the test 955 fails is because I made it return '13' to all the values that can change, and with your update it now means 13 microseconds while it previously meant 13 seconds, so the expected output in the test needs to be adjusted accordingly! |
|
can i launch a specific test per command? |
yes: |
|
k, i also tweaked curl_version() (similar to CURL_GETHOSTNAME, CURL_TIME) to get a stable version string which can be used to test against in the unit-tests. |
|
@bagder ping ... any more ... whishes / hints / suggestions / improvements? |
|
I think it looks fine. We won't merge this until after the pending release as this is a new feature, not a bugfix. It also now needs a rebase (and changed test number since 955 was taken). Maybe spend the time and fix so that all the write-out strings aren't duplicated in the new file? Having them duplicated like this will only cause them to get out of sync and generally be hard to maintain. |
|
rebased to current master + put a new commit ontop which is tackles the duplication of the fields in tool_writeout* … could be some sort of approach to tackle some pieces of the existing tool_writeout.c parts as well. tool_writeout_json.h is kind of useless now, tool_writeout.c could #include "tool_writeout_json.c" directly … but as a first discussion i think the new commit is worth having. |
This commit adds support to generate JSON via the writeout feature:
-w "%{json}"
It leverages the existing infrastructure as much as possible. Thus,
generating the JSON on STDERR is possible by:
-w "%{stderr}%{json}"
This implements a variant of https://github.com/curl/curl/wiki/JSON#--write-out-json.
Makes curl_easy_getinfo() of "variable" numerical content instead return the number set in the env variable `CURL_TIME`. Makes curl_version() of "variable" textual content. This guarantees a stable version string which can be tested against. Environment variable `CURL_VERSION` defines the content.
With the introduction of tool_writeout_json.c the list of fields to write out is significant. This commit refactors some data structures to keep the source of truth to one place only.
|
ping @bagder |
|
Thanks! |
This commit adds support to generate JSON via the writeout feature:
It leverages the existing infrastructure as much as possible. Thus,
generating the JSON on STDERR is possible by:
This implements a variant of https://github.com/curl/curl/wiki/JSON#--write-out-json.