This repository was archived by the owner on Nov 30, 2024. It is now read-only.
Reduce JRuby flakyness by giving it more time to finish #2444
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
PragTob
added a commit
to PragTob/rspec-dev
that referenced
this pull request
Jul 14, 2017
Opposed to what I said in rspec/rspec-core#2444 there is something we can do, I just underestimated its effect. There is `--dev` (see https://github.com/jruby/jruby/wiki/Improving-startup-time#use-the---dev-flag). Locally for the rspec-core --bisect spec this brought the runtime down from 33 to 36 seconds to 21 seconds! It also encompasses disabling invoke dynamic already, so no need for that. It is opposed to server mode that was used however, server mode targets peak performance at the cost of bigger startup and warmup times and is usually intended for running on the server/ benchmarks. It was introduced for no reason apparent to me in bc0b976 and I think --dev fits the use case better and is closer to what most peeps probably run either way. Other changes I did: * collapsed all the envs into one, it shouldn't hurt the other elements in the matrix, we lose the compat version 2.0 but that doesn't seem too important atm if it is please tell me * updated the JRuby version to the most current one
|
No idea what's up with Appveyor but I also can't restart it... Although I could rebase against master, maybe I started off on a wrong parent or something. |
Startup time is still very much a problem with JRuby, hence feature type aruba cukes that invoke rspec a lot of times are still problematic. The bisect specs do this to the extreme, resulting in long spec run times. Locally a single scenario takes 36 seconds to run for me, on a 4-core desktop computer. An overloaded CI might take longer, hence just double the timeout and hope it's enough. Nothing much else we can do, but try using --dev see rspec/rspec-dev#179 ref: rspec#2442
PragTob
force-pushed
the
fix-jruby-flakyness
branch
from
3c6bd70 to
b5efc97
Compare
|
(nothing to rebase against, reworded commit message refing my other PR to get a rebuild) |
|
Thanks! |
MatheusRich
pushed a commit
to MatheusRich/rspec-core
that referenced
this pull request
Oct 30, 2020
Reduce JRuby flakyness by giving it more time to finish
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Startup time is still very much a problem with JRuby, hence
feature type aruba cukes that invoke rspec a lot of times
are still problematic. The bisect specs do this to the extreme,
resulting in long spec run times. Locally a single scenario
takes 36 seconds to run for me, on a 4-core desktop computer.
An overloaded CI might take longer, hence just double the timeout
and hope it's enough. Nothing much else we can do.
ref: #2442
While I'm here, thanks for rspec it's 🚀 - and shoes4 is an OSS project that is rigorously tested with it :)