Stream: shorthand
Topic: Feedback from the field
Brian Kaney (Sep 24 2020 at 21:33):
Hi everyone! After a few months of near daily use of sushi (which we all love!) one thing that would be super great is emphasis on (1) exit codes and (2) making the output optionally machine parsable (both goes for IG Publisher as well). It's kinda tricky now as we are finding ourselves running the output through grep and pattern matching to in our CI/CD publishing pipelines.
Chris Moesel (Sep 24 2020 at 21:38):
Can you provide some more detail or examples regarding what you're looking for? We currently exit w/ 0 as long as there are no errors, and 1 if there are errors. What other types of exit codes would you be looking for? And what is it that you want to be machine-parsable? Do you mean the logs? If so, what level of detail are you looking to parse out?
Grahame Grieve (Sep 24 2020 at 21:38):
what output do you want to parse from the IG Publisher?
Brian Kaney (Sep 24 2020 at 21:43):
I think maybe just IG Publisher might not use error return codes. Also I think both tools might consider errors going to stderr (not stdout).
As far as parsing output, it's mainly stats (like number of errors and number of warnings). We have some tooling where we set gates/thresholds to fail the build (for warnings).
Grahame Grieve (Sep 24 2020 at 21:44):
well., under all circumstances I am aware of, the IGPublisher will set an exit code != 0 if it fails
Grahame Grieve (Sep 24 2020 at 21:44):
have you looked at qa.json and qa.xml?
Brian Kaney (Sep 24 2020 at 21:47):
no, I didn't think about that, as we are parsing the output in our CI/CD build process. One situation that comes to mind is grep for /^Translation failed/ for CQL translation.
Brian Kaney (Sep 24 2020 at 21:52):
(https://github.com/HL7/fhir-ig-publisher/issues/128)
Last updated: Apr 12 2022 at 19:14 UTC
