-
-
Notifications
You must be signed in to change notification settings - Fork 232
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
--write-summary to redirect final JSON output #1773
--write-summary to redirect final JSON output #1773
Conversation
Codecov Report
@@ Coverage Diff @@
## main #1773 +/- ##
==========================================
- Coverage 82.51% 82.50% -0.02%
==========================================
Files 47 47
Lines 8197 8203 +6
Branches 2235 2237 +2
==========================================
+ Hits 6764 6768 +4
- Misses 939 941 +2
Partials 494 494
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
I'm not sure how to test differential code coverage locally so codecov/patch will pass. Any ideas? |
ad4762a
to
6aeb924
Compare
Hey @jfennick , thanks for sharing. There is a lot of important information in the CWL output object (which is the only thing written to /dev/stdout). For example, non-File outputs are only represented in this JSON dump. So I don't think it would be safe to include an option that can lead to dataloss. The could be a And/or there could be an option to save the final output object to a particular path. This is equivalent to redirecting the stdout stream at the command line ( Perhaps that other option could be named |
Gotcha, I didn't notice the difference w.r.t. non-File outputs. I think the easiest / safest choice is your last option, FYI the output object is indeed the only thing printed to stdout, if you use the |
Now codecov/patch is passing and codecov/project is failing. ?? |
Any chance we can get this merged before the holidays? I'm not sure what else I need to do to get codecov/project to pass. |
ef6edf9
to
432bc94
Compare
432bc94
to
a5d63ee
Compare
Excellent, thank you! |
The goal of this PR is to allow users to hide the final output json. For large workflows (particularly workflows with scattering) this can be absolutely massive. If the workflow completes successfully this isn't necessarily a problem. However, if the workflow fails, users will need to scroll up past the final output so they can see the error message(s).
The problem I'm finding is that (despite my urging) users are apparently unable or unwilling to scroll up...
The solution I've chosen here simply adds a CLI flag --no-print-final-output which hides the final output. Note that using --provenance, this information is still available at provenance/workflow/final-output.json
Another solution is instead of using print, the code could use the python logging API. Then developers using the python API could use a logging filter to hide the final output. However, this would not help CLI users.
Another solution is to neither print nor log the final output, but instead to write it directly to a file. However, as noted above, this basically already exists at provenance/workflow/final-output.json