Fix smoke task #1087
Fix smoke task #1087
Conversation
|
:( I can't get the travis failure to reproduce locally. Travis reports the sanity check script to error with: However, locally, I always get: |
|
Fixing this today. I think it's just a few minor changes:
|
When the example app is created for running cukes we need to setup a Gemfile. It needs to share the same dependencies as this repo. To facilitate this, move the common dependencies into a custom Gemfile. Switch to using the proper bundler `eval_gemfile`, which properly handles path location differences, instead of reading a file then using raw `eval`.
Without using a custom Gemfile, the main `rspec-rails` repo bundle is used. Due to how various Rails autoload issues work with bundler, this caused `RSpec::Support` to be automatically loaded by the rails generator. The root cause of this is because `rspec-support` and `rspec-core` are explicitly included in the Gemfile. This differs in behavior from when a normal Rail's app only specifies `rspec-rails` in the Gemfile. Setup an explicit Gemfile to resolve the load difference issues.
|
Waiting on rspec/rspec-support#87 to fix build failures. |
Part of the reason for this not being caught earlier is due to the gemfile being setup to not require the supporting gems by default. This creates a few specs to help manage that.
When the example app is generated it puts a Rails version that is defined by currently installed version. This works great in most situtations, except `master` or other edge branches. The version listed is the current version of Rails, so they diverge. Move how we load rails into a custom Gemfile, which we eval ourselves. We then remove the rails version put into the gemfile and share our custom version. Due to when `rake` and other shell processes fork, the RAILS_VERSION environment variable is properly passed through.
|
Yay! Finally green. ping @JonRowe @myronmarston @samphippen |
| end | ||
| end | ||
| rspec_dependencies_gemfile = File.expand_path("../Gemfile-rspec-dependencies", __FILE__) | ||
| eval_gemfile rspec_dependencies_gemfile |
There was a problem hiding this comment.
Where is eval_gemfile defined?
There was a problem hiding this comment.
It's defined by Bundler I believe: http://rubydoc.info/github/carlhuda/bundler/master/Bundler/Dsl#eval_gemfile-instance_method
There was a problem hiding this comment.
Huh, never knew about that. Elsewhere we've used eval:
https://github.com/rspec/rspec-core/blob/b648cdbd7811b20aa6da0da8bbed8cffdcd1816a/Gemfile#L33
It's not clear to me from that context if the bundler team considers eval_gemfile to be a public API. @xaviershay, do you know? If they don't consider it public I'd prefer we use eval.
There was a problem hiding this comment.
The nice thing about eval_gemfile is it takes care of handling relative paths based on the evaluated Gemfile location, which eval doesn't do.
There was a problem hiding this comment.
It's in the DSL class, pretty sure all though methods are public.
|
Any other concerns with this one? |
no. |
Backport smoke task from pull request #1087
This is the follow up to #1059, in response to #1058. Most of the work was done with @samphippen during Ruby Nation to flush out the root cause and devise a general solution.
This implements proper setup of the test rails application. Previously the rails app used this gem's
Gemfileduring it's execution. Despite usingBundler.with_clean_envin the Rake file, theGemfilestill automatically loads the other rspec gems since they are explicitly listed.Running a rails app which only requires
rspec-railsper the instructions:gem 'rspec-rails', '~> 3.0.0', groups: [:development, :test], will not automatically require the other gems. The other gems will only be loaded if/whenrspec-railsrequires them. Since this was not properly happening with the generator, the error reported in #1054 occurs.Unfortunately, the only way to get the proper dependencies to work when running things locally is to actually list the other rspec gems in the Gemfile. By marking them with
:require => false, we ensure they will not be automatically loaded.Now that the gems are required in two places, 1) the main gem and 2) the test app, it is possible / likely that they will drift. To prevent this, the main rspec related gems have been moved to a shared Gemfile. This is properly loaded in the main Gemfiles. Thus allowing any changes to be properly picked up.