-
-
Notifications
You must be signed in to change notification settings - Fork 2k
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
[Core] Parallel cukes #1389
[Core] Parallel cukes #1389
Conversation
Preliminary release notes:
Anything I missed? |
I would like to update the examples with some configuration that makes them run in parallel but that can be done after merging. |
RE: Release notes. Nope can’t think of anything, other than the massive refactoring ;o) |
Hi @boaty82, Thanks for your making your first contribution to Cucumber, and welcome to the Cucumber committers team! You can now push directly to this repo and all other repos under the cucumber organization! 🍾 In return for this generous offer we hope you will:
On behalf of the Cucumber core team, |
I've merged this a bit earlier then planned to unclog some stuff. Welcome aboard Boaty. |
Very exciting stuff!!!! @boaty82 if you haven't already, please have a look at the roadmap. I think it would be great to extract the timeline formatter to a standalone command line program at some point, when Cucumber-JVM can report results as protobuf messages. That will make the formatter easier to maintain, but more importantly, it will allow any Cucumber implementation to use it. |
If you let me know what branch to work from etc then I’ll happily carry on contributing to this and other parts where and when I can help |
@boaty82 Thanks for your work on this! |
Does this still need doing? If so, I'll happily crack on with this in the next few days - just been too busy recently with work and managing to hurt myself 🤕 |
Yes - we don't want any formatters to be implemented in Cucumber-{jvm,js,ruby,xxx}. As described in the roadmap, all formatters should be standalone command line programs (preferrably go) that can be used by all implementations using the message protocol. |
Have a look at the dots-formatter to get an idea of a very simple implementation. |
Unless I am mistaken it looks like the data defined in messages protocol will need expanding to include the thread id the test ran within. |
Maybe call it executorId. The thread is an implementation detail. |
Is this something that would be considered for the current events? Use case: If the thread(executorId) was available in the the event messages it should be possible to match these up after the run (or during if using a concurrent version of the formatter). Happy to raise this in a new thread if this isn't the right place for this convo. |
It'd be better to raise a new thread for that. |
@aslakhellesoy I cannot get the dotsformatter to build, tried various things and all I get is
|
for (CucumberFeature feature : features) { | ||
for (final PickleEvent pickleEvent : compiler.compileFeature(feature)) { | ||
if (filters.matchesFilters(pickleEvent)) { | ||
executor.execute(new Runnable() { |
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.
If I see this correctly, that will simply swallow any exceptions thrown while executing a pickle - i.e it will log them, dispose the executor thread and then execute the next pickle in a new executor thread.
I have seen this behaviour because there's a bug in my ConcurrentEventListener. It doesn't make the cucumber run fail!
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.
Can you make an issue for that? Ideally we catch all exceptions in the runner and fail the pickle.
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.
See #1628
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
1 similar comment
This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
Notice
This PR replaces Parallel support #1357 and relies on Refactor Runtime #1367
Outline
I’ve previously used another implementation to deliver parallel execution of cucumber tests, however it basically wrapped up the creation and execution of
Runtime
’s, followed by the need to merge the multiple JSON/HTML etc reports that followed.I reviewed the current implementation and also took note of comments in Support concurrent executions of scenarios also I perused all tickets related to running in parallel cukes for other insights
Main changes
Added
--threads
argument to runtime optionsAllows users to specify the (max) number of threads to be used to run the tests
The actual number of threads used will be the smaller of the given
--threads
value and the number of features to be executedTests are placed into a
Queue
and consumed by each thread when needed, resulting in a more performant usage of the threads & less deterministic order of Features being runNew formatter introduced
TimelineFormatter
Which produces reports using vsjis.org timeline to highlight which feature was run on which Thread and when.
Note: the resources (js, html etc) are currently within
cucumber-core
if the PR is accepted then I’d imagine these would have to be moved out into its own project, similarly to cucumber-html.example.zip
Types of changes
-Runtime
constructor now privateRuntime.Builder
introduce to hide away boiler plate setup/instantiation codeChecklist: