Details
-
Type:
Story
-
Status: Won't Fix
-
Resolution: Done
-
Fix Version/s: None
-
Component/s: None
-
Labels:
-
Team:SQuaRE
Description
We need a flow chart that describes how Tasks work. I believe it looks something like parse args->make butler->make Runner->runner.getTargetList()>runner.run()>Task.run(), but I'm sure there are steps I don't know about (and I certainly don't know which files some of the above are implemented in), and I don't know what arguments the base Task system expects at each step.
This has shades of RFC-352, but even before we deal calling run() or runDataRef() there are a bunch of relatively standard steps.
Attachments
Issue Links
Activity
| Component/s | Stack Documentation and UX [ 12880 ] | |
| Team | SQuaRE [ 10302 ] |
| Remote Link | This issue links to "Page (Confluence)" [ 31141 ] |
Good question. The "parse args" sketch above is clearly wrong, but whatever the gen3 "pipetask" equivalent flow chart is, would still be useful for understanding how commands flow through the system.
I'm gonna Won't Fix this; while the logical flow between pipetask subcommands (and by extension, BPS) can certainly be hard to follow, I think the real fix is a reworking of those subcommands and the boundaries between them, because even a nice flowchart would be hard to follow now (and I hate spending time writing documentation as a workaround for interface problems). If we do that well, I think a few examples will then do the job even better than a flowchart, but we'll see. In any case, keeping a ticket with a Gen2-specific description around as a placeholder for "fix the pipetask/BPS docs" doesn't seem useful. New tickets are cheap.
| Resolution | Done [ 10000 ] | |
| Status | To Do [ 10001 ] | Won't Fix [ 10405 ] |
Where does this ticket stand in the gen3 world with runQuantum?