-
Notifications
You must be signed in to change notification settings - Fork 9
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
Use dependency System: Part 2; Marking as unresolvable #197
Conversation
This commit is missing dependency updates
This is especially important with this branch because it exposed a lot of problems
I need to test if this works with subworkflow/foreach. If it doesn't, I don't think that has to block these changes, but it should be an immediate follow-up PR. |
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.
Dropping first impressions on a quick scan: it'll take some more time to digest the details.
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.
Another scan, in a bit more detail.
This ensures that the waitgroup properly waits for all steps. There used to be a race condition that caused it to call Wait before Add()
Fixed improper locking, paths that could lead to double-resolution, and more.
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.
Made a really quick scan through this, making a couple of notes I don't think are a big deal ... but I might as well drop them.
Are we missing a commit here? I thought you were making a few minor changes after the meeting, and I don't see anything. |
Yes. I will push the commit. |
Changes introduced with this PR
The way this works is by marking all outputs that failed as unresolvable.
A callback called
OnStepStageFailure
was created to allow the providers to self-report failure of specific stages within their lifecycle for a step. The callback is required because the DAG itself doesn't know everything.Once all outputs are marked unresolvable, the entire workflow exits at that time. It will not keep things running.
The old way of determining failure is still implemented, but any activation of it is considered a bug, either due to a false activation, or due to a missing mark of unresolvability.
With the bugs fixed in the updated dependencies, the tests are very resilient based on my testing. This will need testing with real-world workflows.
By contributing to this repository, I agree to the contribution guidelines.