You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jul 21, 2020. It is now read-only.
I need to dig in to figure out how is done but basically we add more vars to meta (step.meta I think) on backend like "is_group", "workflow", and "grouping_property", and then like, combine them on frontend, in a weird way
For all steps/files that have those 3 props equal to each other
Is pretty shoddy, was kind of 1 of later things added after everything else was working so kinda hacked it in rather than designed it in
That part would definitely want to refactor in conjunction with backend/caching updates, so that all grouping/ungrouping is performed on frontend instead
Currently the backend logic that adds that step.meta stuff is also a performance enhancement that avoids tracing history of those parallel steps
Backend logic = if same file type, same input argument, and output from same workflow (steps are workflow-runs == instances of workflows), then is assumed to be parallel (and add those 3 aforementioned properties to meta) (edited)
Part of refactoring might be to like remove those group nodes and replace with something else (box showing more graphs or somit, maybe the actual graph(s) but minimized (since we'd have that data on frontend in future)), idk. But yeah that part is probably most subject to be changed at some point (re: any frontend/repo changes)
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Here are notes from Alex:
The text was updated successfully, but these errors were encountered: