Workflow progress bar.#1510
Conversation
cf9df02 to
0f835ef
Compare
|
The code was nice and clean before I considered subworkflows.... now it is not so much - really getting into the weeds. I think I need to simulate multiple subworkflows evolving over time to keep testing this 😅. How to track what we consider a failure is already complex and needs to be a lot more complex - calling the whole thing a failure on a failed job is bad but I'm not sure how to fix it (first crack could be to disable that behavior if there is a single filter failed step anywhere in the workflow - still so wrong though). The display stuff is relatively clean compared to all that I think. The simple recursion the previous tracking did is also not ideal for this display because I think we should bounce around multiple subworkflows and show one at a time for a few seconds and the display of the parent workflow is slightly different than subworkflows. Here is a single workflow and one subworkflow - not from the tracking code just the display component in isolation with minimal synthetic API responses. planemoprogress.mov |
0cb2723 to
6a1fab2
Compare
|
I have rotating multiple subworkflow tracking and tracking subworkflows along with the primary workflow in "parallel" working. I had to implement a cool little invocation-evolution-over-time DSL - might be cool to use when implementing processing failure messages and such. I parameterized the display a bunch too so it should be easy to bike shed. workflowprogress2.mov |
|
Also... in dark mode and more traditional font size. workflowprogressindark.mov |
|
Wow, this is amazing, I think that'll make a huge difference in how usable the CLI is perceived to be. |
6a1fab2 to
290c698
Compare
|
Looks really nice! Tried it out today. One thing I thought of was that it would be nice if the copying of input files also are visualized, that part can take a lot of time. Would be nice if the log output to the terminal is turned of and that we could turn it on when needed, logs can still be found at |
a95640f to
a255fcd
Compare
a255fcd to
1eeb3a0
Compare
|
rich also lets us create clickable links (b156755): 
|
06e415f to
4a2fc83
Compare
4d484d3 to
2eec905
Compare
Can't use classvars for a lot of the stuff, those are essentially globals. Fixes the tests.
Think we still have some work to do once there are failing jobs.
`--no-early-termination` is the current behavior. `--fail-fast` could be an option to implement.
a176376 to
5d65ee2
Compare
2149878 to
f6d0ad5
Compare
Talked about for Galaxy Live! A progress bar would be more useful than the Galaxy logs for running workflows.
This PR is just in early stages but I wanted to have a PR to track progress and get feedback. My approach is develop the progress bar in the abstract with synthetic API responses, create a Planemo command "workflow_track" that can just be attached to existing invocations like "planemo workflow_test_on_invocation" at runtime, and then once it seems to work replace the wait function
_wait_for_invocation_jobsin planemo.galaxy.activity with the progress bar. "planemo workflow_track" could be used to test how workflow errors render also.The implementation I have so far is using Rich (https://rich.readthedocs.io/en/latest/style.html). It seems a bit more full featured than click's builtin component and less opinionated than tqdm.