Push rechazó, no compiló la aplicación de ruby

actualmente estoy en el capítulo 3 del tutorial de michael hartl y sigo encontrándome con este problema:

C:/Users/HuiHui/sutdweb/spec/spec_helper.rb:82:in `block in <top (requinetworking)>': u ninitialized constant Capybara (NameError) 

Este es mi Gemfile.rb:

 source 'https://rubygems.org' ruby '1.9.3' gem 'rails', '4.1.1' gem 'sqlite3-ruby', '1.3.1', :require => 'sqlite3' group :development, :test do gem 'sqlite3' gem 'rspec-rails' end group :test do gem 'selenium-webdriver', '2.35.1' gem 'capybara', '2.3.0' end gem 'sass-rails', '4.0.1' gem 'uglifier', '2.1.1' gem 'coffee-rails', '4.0.1' gem 'jquery-rails', '3.0.4' gem 'turbolinks', '1.1.1' gem 'jbuilder', '1.0.2' group :doc do gem 'sdoc', '0.3.20', require: false end group :production do gem 'pg', '0.15.1' gem 'rails_12factor', '0.0.2' end 

y este es mi spec_helper.rb:

  # This file was generated by the `rails generate rspec:install` command. Conventionally, all # specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`. # The generated `.rspec` file contains `--require spec_helper` which will cause this # file to always be loaded, without a need to explicitly require it in any files. # # Given that it is always loaded, you are encouraged to keep this file as # light-weight as possible. Requiring heavyweight dependencies from this file # will add to the boot time of your test suite on EVERY test run, even for an # individual file that may not need all of that loaded. Instead, make a # separate helper file that requires this one and then use it only in the specs # that actually need it. # # The `.rspec` file also contains a few flags that are not defaults but that # users commonly want. # # See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration # require 'rspec/rails' # require 'active_support' # require 'active_support/core_ext' require 'rspec/Rails' require 'capybara/Rails' RSpec.configure do |config| # The settings below are suggested to provide a good initial experience # with RSpec, but feel free to customize to your heart's content. # These two settings work together to allow you to limit a spec run # to individual examples or groups you care about by tagging them with # `:focus` metadata. When nothing is tagged with `:focus`, all examples # get run. config.filter_run :focus config.run_all_when_everything_filtenetworking = true # Many RSpec users commonly either run the entire suite or an individual # file, and it's useful to allow more verbose output when running an # individual spec file. if config.files_to_run.one? # Use the documentation formatter for detailed output, # unless a formatter has already been configunetworking # (eg via a command-line flag). config.default_formatter = 'doc' end # Print the 10 slowest examples and example groups at the # end of the spec run, to help surface which specs are running # particularly slow. config.profile_examples = 10 # Run specs in random order to surface order dependencies. If you find an # order dependency and want to debug it, you can fix the order by providing # the seed, which is printed after each run. # --seed 1234 config.order = :random # Seed global randomization in this process using the `--seed` CLI option. # Setting this allows you to use `--seed` to deterministically reproduce # test failures related to randomization by passing the same `--seed` value # as the one that triggenetworking the failure. Kernel.srand config.seed # rspec-expectations config goes here. You can use an alternate # assertion/expectation library such as wrong or the stdlib/minitest # assertions if you prefer. config.expect_with :rspec do |expectations| # Enable only the newer, non-monkey-patching expect syntax. # For more details, see: # - http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax expectations.syntax = :expect end # rspec-mocks config goes here. You can use an alternate test double # library (such as bogus or mocha) by changing the `mock_with` option here. config.mock_with :rspec do |mocks| # Enable only the newer, non-monkey-patching expect syntax. # For more details, see: # - http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/ mocks.syntax = :expect # Prevents you from mocking or stubbing a method that does not exist on # a real object. This is generally recommended. mocks.verify_partial_doubles = true end config.include Capybara::DSL end 

rails_helper.rb:

 # This file is copied to spec/ when you run 'rails generate rspec:install' ENV["RAILS_ENV"] ||= 'test' require 'spec_helper' require File.expand_path("../../config/environment", __FILE__) require 'rspec/rails' # Requires supporting ruby files with custom matchers and macros, etc, in # spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are # run as spec files by default. This means that files in spec/support that end # in _spec.rb will both be requinetworking and run as specs, causing the specs to be # run twice. It is recommended that you do not name files matching this glob to # end with _spec.rb. You can configure this pattern with with the --pattern # option on the command line or in ~/.rspec, .rspec or `.rspec-local`. Dir[Rails.root.join("spec/support/**/*.rb")].each { |f| require f } # Checks for pending migrations before tests are run. # If you are not using ActiveRecord, you can remove this line. ActiveRecord::Migration.maintain_test_schema! RSpec.configure do |config| # Remove this line if you're not using ActiveRecord or ActiveRecord fixtures config.fixture_path = "#{::Rails.root}/spec/fixtures" # If you're not using ActiveRecord, or you'd prefer not to run each of your # examples within a transaction, remove the following line or assign false # instead of true. config.use_transactional_fixtures = true # RSpec Rails can automatically mix in different behaviours to your tests # based on their file location, for example enabling you to call `get` and # `post` in specs under `spec/controllers`. # # You can disable this behaviour by removing the line below, and instead # explicitly tag your specs with their type, eg: # # RSpec.describe UsersController, :type => :controller do # # ... # end # # The different available types are documented in the features, such as in # https://relishapp.com/rspec/rspec-rails/docs config.infer_spec_type_from_file_location! end 

cuando hice git push heroku , me dieron el siguiente error:

  Installing rdoc 3.12.2 Installing pg 0.15.1 An error occurnetworking while installing sqlite3-ruby (1.3.1), and Bundler cann ot continue. Make sure that `gem install sqlite3-ruby -v '1.3.1'` succeeds before bund ling. ! ! Failed to install gems via Bundler. ! ! Detected sqlite3 gem which is not supported on Heroku. ! https://devcenter.heroku.com/articles/sqlite3 ! ! Push rejected, failed to compile Ruby app To git@heroku.com:sutdweb.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git@heroku.com:sutdweb.git' 

¿Por qué es rechazado el empuje? ¿Alguien puede arrojar algo de luz sobre esto?

Capybara

En tu Gemfile , mueve el capybara de tus gems de test :

 #Gemfile gem `capybara` 

Heroku solo instalará las gems generic y de production (IE usa la bundle install --without test development del bundle install --without test development command de bundle install --without test development )

Esto significa que cuando usas el command require 'Capybara' sin tener la gem instalada en Heroku, terminarás con el error que has recibido.

Sqlite

En segundo lugar, está intentando instalar la gem SQLite, que no es compatible con Heroku.

Deshágase de la gem SQLite de su file gem de production esta manera:

 #Gemfile group :development do gem 'sqlite' end 

Esto debería ayudar a su sistema a instalar las gems restantes para que funcione

Como mencionó @cupcake , parece que tu Gemfile tiene SQLite en el grupo de development , sin embargo, estás haciendo reference a otra gem gem 'sqlite3-ruby', '1.3.1', :require => 'sqlite3' -> esto debería ser colocado en su grupo de development también:

 #Gemfile group :development do gem 'sqlite3-ruby', '1.3.1', :require => 'sqlite3' end 

Si aplica los cambios a su Gemfile, debe realizar los siguientes pasos:

 $ git add . $ git commit -a -m "Heroku" $ git push heroku master