Hi
I use the ci_reporter gem for builds on my CI machine (hudson).
Prior to rspec 2.4, environment options would override commandline
options. So the gem used this to change the formatter and require its
files.
In 2.4, that order has been reversed.
the thing is 2.4 supports multiple formatters, so there is another
suggestion.
RSpec::Core::ConfigurationOptions
def parse_options
@options = begin
options_to_merge = []
if custom_options_file
options_to_merge << custom_options
else
options_to_merge << global_options
options_to_merge << local_options
end
options_to_merge << env_options
options_to_merge << command_line_options
options_to_merge.inject do |merged, options|
merged.merge(options)
end
end
end
the last section, instead of merging hashes, could combine the values
of all hashes with the keys “–require” or “–format”. So you get the
default formatter and the extra formatter that ci_reporter introduces.
On Jan 26, 2011, at 8:43 AM, vishnu wrote:
Hi
I use the ci_reporter gem for builds on my CI machine (hudson).
Prior to rspec 2.4, environment options would override commandline
options. So the gem used this to change the formatter and require its
files.
In 2.4, that order has been reversed.
This has since been restored to its previous behavior, to be released in
2.5. See RSpec should prefer SPEC_OPTS to cmdline options (regression in 2.4.0) · Issue #276 · rspec/rspec-core · GitHub.
options_to_merge << local_options
the last section, instead of merging hashes, could combine the values
of all hashes with the keys “–require” or “–format”. So you get the
default formatter and the extra formatter that ci_reporter introduces.
I think I’d want a separate API for this - something like:
~/.rspec
–format-that-is-not-overridden html
–out-that-is-not-overridden ~/rspec/this-project/report.html
But maybe a bit less verbose Either that or maybe a marker option
like this:
~/.rspec
–color
–backtrace
–no-override
–require ~/path/to/file/to/always/require
–format html
–out ~/rspec/this-project/report.html
Then require, format, and out options following the --no-override option
would be additive.
WDYT? Other ideas?
ah. Because people currently depend on the override behaviour? This
seems to be a historical artifact though. I’d expect something that
wants to override other configuration to have to specify that it does,
not the other way around?
so maybe SPEC_OPTS should have an --overide option to override
behaviour specified through other configuration means?