-
-
Notifications
You must be signed in to change notification settings - Fork 762
RSpec should prefer SPEC_OPTS to cmdline options (regression in 2.4.0) #276
Comments
Do you want to submit a patch? If not I'll take care of it. |
At the moment I didn't managed to correctly configure rspec-dev so I cannot attach a test for my fix. |
David, I've configured rspec-dev environment, I'll attach a patch |
See iromeo@aa706bf |
Sorry for not asking this before, but I didn't really think about it until going to merge this. My instinct is that command line options should take precedence over anything else, even those defined in SPEC_OPTS. Is there a problem that is happening as a result of this ordering? |
At least rspec rake task passes its options using cmdline thus RubyMine and our CI Server (TeamCity) cannot patch user's rake task options via SPEC_OPTS env variable. We don't force user to adapt his rake tasks for our IDE / CI. I suppose it is better to allow the same code to be executed in console and in our products. The difference is only in results presentation but implementation details are hidden.
I suppose both ways are reasonable. SPEC_OPTS priority is better for patching default rspec behaviour. |
Prefer SPEC_OPTS to cli
|
Thanks! |
Hello,
After "Restore --options CLI option from rspec-1" (d7e4033) refactoring RSpec 2.0 starts prefer cmdline options to options preferred via env variables. According to diff the bug is evident:
was replaced to
....
options_to_merge << env_options
options_to_merge << command_line_options
Thus merge order was occasionally changed. Fix is just to swap this two lines.
The text was updated successfully, but these errors were encountered: