-
Notifications
You must be signed in to change notification settings - Fork 13
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
Workflow graph structure #1209
Workflow graph structure #1209
Conversation
56c96f7
to
6ce9291
Compare
Co-Authored-By: Nicolas Mahé <nicolas@mesg.com>
3fc0f0a
to
2dfde78
Compare
Key string `hash:"name:3" validate:"required"` | ||
Key string `hash:"name:1" validate:"required"` | ||
Trigger Trigger `hash:"name:2" validate:"required"` | ||
Nodes []Node `hash:"name:3" validate:"dive,required"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What do you think about moving the graph as a separate structure? In that case you can control and test all graph functions like searching path, walking order and more without Workflow and workflow will just use it like:
type Workflow struct {
// ....
g wgraph
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for now, the workflow is pretty much only the graph but yes I agree that could be nice. I would still keep that as a future refactoring if the package gets bigger or we need to reuse the graph
|
||
// Edge describes the instructions for the workflow to execute a task | ||
type Edge struct { | ||
Src string `hash:"name:1" validate:"required"` |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see a validation if the edge has proper src and dst.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yes not yet, I wanted to add the validation of nodes/edges and also the instances on another pr
Fixed workflows to send to API:
|
Update the structure of the workflow with a graph approach.
The workflow definition is now created based on a list of nodes and a list of edges that connects these nodes.
Every node need to be unique in the workflow and will be identifiable. With the node identifiable we can now store the current step when creating execution and can drop the height support that was not valid when a workflow was triggered by a result of the same workflow and the same task.
With this new
stepID
we can simply find the children of this node in the workflow definition graph and execute all the children's tasks.stepID
TO TEST
Create and start the services with the cli or API.
Create one or all the following workflow(s) with the API
eg:
grpcurl -plaintext -d "$(cat result.json| jq -c .)" localhost:50052 api.Workflow/Create
Then you see the workflow by running either an event with
or a task