-
Notifications
You must be signed in to change notification settings - Fork 412
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
Upstream Jane Street changes to Dune engine #8362
Conversation
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.
Do we want to expose the stop_on_first_error
behaviour to the user via a config option?
@@ -96,13 +96,15 @@ type t = | |||
; execution_parameters : dir:Path.Source.t -> Execution_parameters.t Memo.t | |||
; source_tree : (module Source_tree) | |||
; action_runner : Action_exec.input -> Action_runner.t option | |||
; action_runners : unit -> Action_runner.t list |
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's the difference between this and the field above?
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.
First one is for selecting the appropriate action runner based on the actions, second one is for notifying all action runners. Merging those is non-trivial since selection depends on some JS-specific code. We plan to refactor this but for now we're trying to minimize the diff between our version and upstream.
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.
Very well. Can you include a comment in the mli that says this will be refactored at a later date? Descriptions of the fields would also be nice but not necessary.
As discussed offline: the test suite reveals that our cycles errors aren't marshallable. We should be able to fix that. I've glanced over the code and there's a couple of things I've noticed that are missing:
I'm not sure if that was intentional, but it's fine to introduce these changes in subsequent PR's if you prefer. |
That would be nice, we implemented that at JS but our front-end is different. |
Yeah, both are intentional, I'll do it in later PRs. |
@@ -96,13 +96,15 @@ type t = | |||
; execution_parameters : dir:Path.Source.t -> Execution_parameters.t Memo.t | |||
; source_tree : (module Source_tree) | |||
; action_runner : Action_exec.input -> Action_runner.t option | |||
; action_runners : unit -> Action_runner.t list |
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.
Very well. Can you include a comment in the mli that says this will be refactored at a later date? Descriptions of the fields would also be nice but not necessary.
OK, once this PR is merged we should open an issue about adding this feature in. We can discuss the details in the issue. |
Signed-off-by: Diana Kalinichenko <dkalinichenko@janestreet.com>
Signed-off-by: Diana Kalinichenko <dkalinichenko@janestreet.com>
Looks like it's not just cycle errors that can be raised in |
Looks like coveralls is getting confused by this branch being named |
+ minor changes to Stdune and Dune rules