jasmine / jasmine-gem

Jasmine ruby gem
682 stars 275 forks source link

Server restarts itself on exit #178

Closed zznq closed 10 years ago

zznq commented 10 years ago

I have a rails 4 app and I am using version 2.0.0.rc4 of the jasmine gem. Whenever I run the jasmine server bundle exec rake jasmine:server and then close it with <Ctrl+C> it will restart.

Also, when I run bundle exec rake jasmine:ci it starts the server and runs the test, then restarts the server which causes a rake aborted!.

Any idea why this might be happening?

ragaskar commented 10 years ago

I can't really think of anything that could be happening from the information you've provided -- this is the first report of this type of problem. Could you paste in your Gemfile and maybe some of the output from the rake tasks and perhaps I can give you some suggestions?

ragaskar commented 10 years ago

Also, rc4 had a exit code bug, please update to latest.

zznq commented 10 years ago

Thanks, I did upgrade once I saw this and that didn't help.

Gemfile

source 'https://rubygems.org'

# Bundle edge Rails instead: gem 'rails', github: 'rails/rails'
gem 'rails', '4.0.0'
gem 'unicorn'

gem 'pg'
gem 'devise'
gem 'omniauth'
gem 'omniauth-oauth2'

gem 'simple_form'

gem 'acts-as-taggable-on'

gem 'rocket_pants'

# Assets
# asset group was removed from rails 4
gem 'haml-rails'
gem 'sass-rails', '~> 4.0.0'
gem 'bootstrap-sass', '~> 3.0.0.0.rc'
gem 'coffee-rails', '~> 4.0.0'
gem 'yui-compressor'
gem 'jquery-rails'
gem 'uglifier'
gem 'css_sprite'

gem 'active_model_serializers'

gem 'backbone-on-rails'

group :development do
  gem 'thin'
  gem 'better_errors'
end

group :test do
  gem 'rspec-rails'
  gem 'shoulda-matchers'

  gem 'capybara'
  gem 'capybara-webkit'

  gem 'factory_girl_rails'
  gem 'faker'
  gem 'database_cleaner'
end

group :development, :test do
  gem 'pry-rails'
  gem 'pry-stack_explorer'
  gem 'pry-debugger'

  # jasmine <= 1.3.2 is broken for rails 4
  gem 'childprocess'
  gem 'jasmine', "~> 2.0.0.rc5"
end

group :production do
  gem 'rails_12factor'
end

group :doc do
  # bundle exec rake doc:rails generates the API under doc/api.
  gem 'sdoc', require: false
end

ruby '2.0.0'

rake jasmine output

$ brake jasmine
your server is running here: http://localhost:8888/
your tests are here:         /Users/zznq/Projects/railroad/kohlrabi/spec/javascripts
your source files are here:  /Users/zznq/Projects/railroad/kohlrabi

Thin web server (v1.6.1 codename Death Proof)
Maximum connections set to 1024
Listening on 0.0.0.0:8888, CTRL+C to stop
^CStopping ...
your server is running here: http://localhost:8888/
your tests are here:         /Users/zznq/Projects/railroad/kohlrabi/spec/javascripts
your source files are here:  /Users/zznq/Projects/railroad/kohlrabi

Thin web server (v1.6.1 codename Death Proof)
Maximum connections set to 1024
Listening on 0.0.0.0:8888, CTRL+C to stop
^CStopping ...

rake jasmine:ci output

$ brake jasmine:ci
Thin web server (v1.6.1 codename Death Proof)
Maximum connections set to 1024
Listening on 0.0.0.0:53429, CTRL+C to stop
Waiting for jasmine server on 53429...
jasmine server started.
2013-11-11 09:39:34.361 phantomjs[5429:d07] *** WARNING: Method userSpaceScaleFactor in class NSView is deprecated on 10.7 and later. It should not be used in new applications. Use convertRectToBacking: instead. 
2013-11-11 09:39:35.040 phantomjs[5429:d07] CoreText performance note: Client called CTFontCreateWithName() using name "Times New Roman" and got font with PostScript name "TimesNewRomanPSMT". For best performance, only use PostScript names when calling this API.
2013-11-11 09:39:35.040 phantomjs[5429:d07] CoreText performance note: Set a breakpoint on CTFontLogSuboptimalRequest to debug.

21 specs, 0 failures
Thin web server (v1.6.1 codename Death Proof)
Maximum connections set to 1024
Listening on 0.0.0.0:53429, CTRL+C to stop
rake aborted!
no acceptor (port is in use or requires root privileges)
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/eventmachine-1.0.3/lib/eventmachine.rb:526:in `start_tcp_server'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/eventmachine-1.0.3/lib/eventmachine.rb:526:in `start_server'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/thin-1.6.1/lib/thin/backends/tcp_server.rb:16:in `connect'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/thin-1.6.1/lib/thin/backends/base.rb:63:in `block in start'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/thin-1.6.1/lib/thin/backends/base.rb:70:in `call'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/thin-1.6.1/lib/thin/backends/base.rb:70:in `start'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/thin-1.6.1/lib/thin/server.rb:162:in `start'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/rack-1.5.2/lib/rack/handler/thin.rb:16:in `run'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/rack-1.5.2/lib/rack/server.rb:264:in `start'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/jasmine-2.0.0.rc5/lib/jasmine/server.rb:16:in `start'
/Users/zznq/.rvm/gems/ruby-2.0.0-p247@kohlrabi/gems/jasmine-2.0.0.rc5/lib/jasmine/tasks/jasmine.rake:33:in `block (3 levels) in <top (required)>'
Tasks: TOP => jasmine:ci
(See full trace by running task with --trace)
tjarratt commented 10 years ago

Does this happen if you use WeBrick instead of Thin?

zznq commented 10 years ago

Yes, both server have the same behavior.

jefflunt commented 10 years ago

Same behavior with rc5 tonight.

I started off with rails 3.2.11 and jasmine 1.3.2, with some existing tests.

Then, the app was upgraded to rails 4.0.1, and I added some code to my javascript such that my javascript under test of jasmine then relied upon jQuery. This led me to a problem where I realized jquery wasn't loading (or at least, wasn't loading in the proper order) for my jasmine tests.

I did some reading and it looked like my issue was possibly asset pipeline related, and that jasmine 2.0.0.rc5 might be a better route.

I changed my Gemfile, then re-ran bundle exec rails g jasmine:install. Afterward I was having the same double-starting Webrick problem. The second time you kill the server it stops for good - but it would start twice everytime, just like @zznq's report.

My Gemfile (in the broken, double-starting state):

#
gem "rails", '4.0.1'
gem "pg"
gem "haml"
gem "authlogic"
gem "aasm"
gem "capistrano"
gem "chronic"
#gem "validates_timeliness"
gem 'exception_notification'
gem 'american_date'
gem "hoe"
gem "rest-client"
gem "less-rails"
gem "therubyracer"
gem "twitter-bootstrap-rails","~> 2.2.8"
gem 'jquery-rails'
gem 'uglifier'
gem 'sass-rails'

#authorization
gem "cancan"

#data-capture
gem "simple_form"
gem "dentaku"

#aker
gem "bcdatabase"
gem "aker"
gem "aker-rails", :github => 'NUBIC/aker-rails', :branch => 'rails4'
gem "aker-nubic"

gem "uuid"

gem "populator"

group :development,:test,:hudson do
  gem 'annotate', '~> 2.5.0'
  gem 'simplecov'
  gem "factory_girl_rails", "~> 4.0"
  gem "faker"
  gem "rspec"
  gem "rspec-rails"
  gem "webrat"
  gem 'launchy'
  gem "database_cleaner"
  gem "debugger"
  gem "jasmine", "2.0.0.rc5"
end

As noted in the linked StackOverflow question/answer, I wound up going back to jasmine 1.3.2 and rails 4.0.1 and it worked fine after I better understood how the jasmine config file worked. That's the config I'm sticking with for now.

After going back to jasmine 1.3.2 the problem stopped in my particular case.

slackersoft commented 10 years ago

This sounds like it's probably due to how rake treats tasks that are re-defined and how jasmine used to install it's rake tasks.

Previously jasmine was adding:

require 'jasmine'
load 'jasmine/tasks/jasmine.rake'

to your Rakefile to get all of the rake tasks loaded properly. Jasmine now loads its rake tasks properly with the default Rails Application.load_tasks and the jasmine specific lines are no longer necessary.

If you still have the jasmine specific rake task loading in your Rakefile, the jasmine tasks will be loaded twice. In rake a new task block doesn't overwrite a previously defined task block, but just appends its actions to the list for that task. This means that rake is actually running the tasks twice.

zznq commented 10 years ago

Thanks, @slackersoft that looks like it was the issue! Just out of curiosity, would there have been some way to determine that is wad loading twice? rake -P had the same output with or without the extra lines in my rakefile.

slackersoft commented 10 years ago

I don't know of any way to tell that rake has a task defined twice other than seeing it run multiple times.

tjgrathwell commented 10 years ago

In case anyone stumbles across this no acceptor (port is in use or requires root privileges) issue again, I just had this problem with a project but with a cause other than load 'jasmine/tasks/jasmine.rake'.

It turned that loading the gem gmaps4rails 1.5.6 was accidentally causing jasmine.rake to be loaded again somehow. The 2.x version of gmaps4rails doesn't have this problem, so I sucked it up and upgraded. But if anyone else sees this issue they might want to drop some kind of a trace into jasmine.rake to reveal where it's being double-loaded.