Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Rspec 3.7.0 is showing Puma logs during spec suite #1897

Closed
RemyMaucourt opened this issue Oct 25, 2017 · 35 comments
Closed

Rspec 3.7.0 is showing Puma logs during spec suite #1897

RemyMaucourt opened this issue Oct 25, 2017 · 35 comments

Comments

@RemyMaucourt
Copy link

I'm building a Rails 5.1 app, and I just upgraded Rspec from 3.6.0 to 3.7.0, and rspec-rails from 3.6.1 to 3.7.1.

Since this upgrade, that puma starting log is displayed during my spec suite.

Puma starting in single mode...
* Version 3.10.0 (ruby 2.4.1-p111), codename: Russell's Teapot
* Min threads: 0, max threads: 1
* Environment: test
* Listening on tcp://0.0.0.0:36775
Use Ctrl-C to stop

Has anything changed in the rspec configuration?

(Screen capture in stackoverflow post)

@deivid-rodriguez
Copy link
Contributor

Same here, I fixed it with ActionDispatch::SystemTesting::Server.silence_puma = true.

@fables-tales
Copy link
Member

this configuration option should default to true. Do you have capybara and puma installed?

@roberts1000
Copy link

roberts1000 commented Nov 6, 2017

I just ran into this as well. It looks like the first spec example, that runs with js: true, triggers the log output.

@JonRowe
Copy link
Member

JonRowe commented Nov 16, 2017

Can you try master? We've delayed loading system test integration which should eliminate this issue for you.

@roberts1000
Copy link

Hi. I just gave 3.7.2 a shot and it's working great now. Thanks!

@sarojkh
Copy link

sarojkh commented Dec 15, 2017

@roberts1000 I upgraded to 3.7.2 as well, but still see the Puma log. Are you sure it wasn't something else?

@roberts1000
Copy link

@sarojkh When I was testing this, the only change I made to the Gemfile.lock was to update rspec and it's dependencies. 3.7.2 solved the problem in my environment.

@swrobel
Copy link

swrobel commented Dec 19, 2017

I'm also on 3.7.2 and still seeing Puma in my test output. Rails 5.2.0.beta2 if that's important. Also, I have the following in my rails_helper although removing it doesn't seem to change anything:

  config.before(:each, type: :system) do
    driven_by :selenium, using: :headless_chrome
  end

@JonRowe
Copy link
Member

JonRowe commented Dec 19, 2017

Have you tried ActionDispatch::SystemTesting::Server.silence_puma = true

@swrobel
Copy link

swrobel commented Dec 19, 2017

@JonRowe thought rspec-rails was supposed to set that, but where would be the preferred place to set that manually?

@JonRowe
Copy link
Member

JonRowe commented Dec 19, 2017

We do set it if it exists at the time of load, but its possible a load order issue means it's not set when we try to. In your rails_helper.rb I would try.

@swrobel
Copy link

swrobel commented Dec 19, 2017

Also had to add require 'action_dispatch/system_test_case' otherwise I get uninitialized constant ActionDispatch::SystemTesting but regardless that didn't work. I'm running w/ bundle exec so spring shouldn't be an issue...

@JonRowe
Copy link
Member

JonRowe commented Dec 19, 2017

Try before(:all, type: :system) { ActionDispatch::SystemTesting::Server.silence_puma = true }

@swrobel
Copy link

swrobel commented Dec 19, 2017

Unfortunately that didn't do it either

@swrobel
Copy link

swrobel commented Dec 20, 2017

The following in rails_helper is the only thing I've found that works so far:

  config.before(:all, type: :system) do
    Capybara.server = :puma, { Silent: true }
  end

So weird...

@rsl
Copy link

rsl commented May 18, 2018

i'm getting this and none of these solutions seem to work.
gem 'rails', '~> 5.1.1' gem 'rspec-rails', '~> 3.5.0', require: false gem 'rspec-given', '~> 3.8.0', require: false gem 'rspec_junit_formatter', require: false

[rspec_junit_formatter is keeping us from upgrading rspec-rails]

@JonRowe
Copy link
Member

JonRowe commented May 18, 2018

@rsl if you can't upgrade rspec-rails nothing will work

@rsl
Copy link

rsl commented May 18, 2018

@JonRowe dang, well thanks for the answer

@eric-hemasystems
Copy link

Dug into this a bit to determine the root cause although I need advice regarding the resolution path. I see it mostly as a design problem in Rails.

  1. When rspec sees that a system test is being run it loads action_dispatch/system_test_case.
  2. Rails loads all the parts of ActionDispatch::SystemTestCase and then before returning actually boots the server. Simply doing a require 'action_dispatch/system_test_case' boots the server.
  3. This means that even though rspec attempts to configure puma to be silent, by that time it has already booted (noisily).

I see this as a design problem in Rails because it provides a configuration option, but simply loading the library makes it too late to actually use that configuration.

If we wanted to solve this in rspec the solution would be to first load the "server" slice of the system test library to make the config, then load the rest of the system test library. So instead of:

require 'action_dispatch/system_test_case'
ActionDispatch::SystemTesting::Server.silence_puma = true

We would do:

require 'action_dispatch/system_testing/server'
ActionDispatch::SystemTesting::Server.silence_puma = true
require 'action_dispatch/system_test_case'

This seems a bit convoluted. Better would be for Rails to be changed so that simply requiring action_dispatch/system_testing doesn't boot the server. The calling code would need to then actually boot the server when it saw fit. This gives an opportunity to make any necessary config of that server.

If you want to work around this issue in the meantime you can place the following in your rails_helper.rb file (no need to put it in a before callback, just before rspec is confiugred is fine):

require 'action_dispatch/system_testing/server'
ActionDispatch::SystemTesting::Server.silence_puma = true

If this project is fine with working around Rails I can create a patch against this. OTOH if this project would rather get things fixed in Rails so it can be actually configured I can open a ticket on the Rails project.

@fables-tales
Copy link
Member

Hi Folks,

RSpec rails will now do this for you if you're on a high enough version fo rails: https://github.com/rspec/rspec-rails/blob/master/lib/rspec/rails/example/system_example_group.rb#L74.

Please upgrade your RSpec Rails and Rails versions and that should fix it for you :)

@eric-hemasystems
Copy link

I don't believe it does. The code you pointed to runs too late. See my previous message for the full explanation.

@fables-tales fables-tales reopened this Jun 22, 2018
@fables-tales
Copy link
Member

@eric-hemasystems can you provide a rails app to clone that reproduces this following these exact steps:

Thanks for the issue. We need a little more detail to be able to reproduce this.

Could you please provide us with a rails app that we can clone that demonstrates the issue. Specifically it'd be great if

  1. you could rails new an application and commit
  2. make all the changes necessary to reproduce the issue and commit

then, provide us with a description of how to clone your application and reproduce the issue.

Thanks :)

@roberts1000
Copy link

roberts1000 commented Jun 23, 2018

It's slightly different, but maybe it's related. When I run RSpec (with capybara), I can trigger

Capybara starting Puma...
* Version 3.11.4 , codename: Love Song
* Min threads: 0, max threads: 4
* Listening on tcp://127.0.0.1:37067

Here's a simple Rails app that reproduces the issue: https://github.com/roberts1000/puma_in_rspec_output. Instructions are in the app's README.

@eric-hemasystems
Copy link

@samphippen - Here is a sample repo that demonstrates the problem, shows my work-around fixing it and provides exactly how this repo was reproduced in the README. Let me know if you need anything further to confirm this is a problem.

https://github.com/eric-hemasystems/rspec_system_puma_output

@jrochkind
Copy link
Contributor

jrochkind commented Feb 26, 2019

OK, will report to puma, thanks. (I'm still wondering if it's got to do with the combo of rails system tests and puma setup though)

its an ordering issue dependant on when puma is booted, the config option needs to happen before puma boots to take affect.

Is there anything I can do in my app to make sure the ordering is correct? Is it as simple as making sure rspec-rails is in the Gemfile before puma?

@JonRowe
Copy link
Member

JonRowe commented Feb 27, 2019

It is not, it is down to how you boot your application, if you need a file run before anything else you must use the --require option on the RSpec cli, either via a config file (such as .rspec) or directly.

This is why the generated install drops a --require spec_helper in your .rspec, as it means the top of your spec_helper.rb is evaluated first. With the split of spec_helper.rb and rails_helper.rb it becomes a bit more complicated, as at some point Rails will be loaded, and the rails_helper.rb loaded, ideally the rails_helper.rb is loaded first but various auto load scenarios will prevent this.

If all your specs are rspec-rails specs you could put require 'rails_helper' at the top of your spec_helper.rb, but that loses some benefits. Alternatively you could load just capybara and puma at the top of your spec helper and configure it.

AlanGabbianelli pushed a commit to alphagov/local-links-manager that referenced this issue Apr 16, 2019
AlanGabbianelli pushed a commit to alphagov/govuk_test that referenced this issue Apr 16, 2019
This is to silence Puma logs and prevent it from writing
```
Puma starting in single mode...
* Version 3.10.0 (ruby 2.4.1-p111), codename: Russell's Teapot
* Min threads: 0, max threads: 1
* Environment: test
* Listening on tcp://0.0.0.0:36775
Use Ctrl-C to stop
```
while running the test suite.

See rspec/rspec-rails#1897 for more context.
AlanGabbianelli pushed a commit to alphagov/local-links-manager that referenced this issue Apr 16, 2019
This versions silences Puma logs during spec suite:
rspec/rspec-rails#1897
AlanGabbianelli pushed a commit to alphagov/local-links-manager that referenced this issue Apr 16, 2019
This versions silences Puma logs during spec suite:
rspec/rspec-rails#1897
gabebw added a commit to gabebw/suspenders that referenced this issue Jun 19, 2019
When Capybara starts the first JavaScript spec of a run, it starts Puma
and prints out the Puma startup messages:

    Capybara starting Puma...
    * Version 3.12.1 , codename: Llamas in Pajamas
    * Min threads: 0, max threads: 4
    * Listening on tcp://127.0.0.1:62516

By setting `Silent: true`, we can prevent those messages from being
printed.

A bit of background: rspec/rspec-rails#1897

Proof that Capybara uses Puma as its default server: https://github.com/teamcapybara/capybara/blob/3.24.0/lib/capybara.rb#L247-L249
composerinteralia pushed a commit to thoughtbot/suspenders that referenced this issue Jun 21, 2019
When Capybara starts the first JavaScript spec of a run, it starts Puma
and prints out the Puma startup messages:

    Capybara starting Puma...
    * Version 3.12.1 , codename: Llamas in Pajamas
    * Min threads: 0, max threads: 4
    * Listening on tcp://127.0.0.1:62516

By setting `Silent: true`, we can prevent those messages from being
printed.

A bit of background: rspec/rspec-rails#1897

Proof that Capybara uses Puma as its default server: https://github.com/teamcapybara/capybara/blob/3.24.0/lib/capybara.rb#L247-L249
claudioclutter added a commit to clutter/mdma that referenced this issue Dec 5, 2019
@aledelsur
Copy link

aledelsur commented Dec 18, 2019

This configuration on the rails_helper.rb worked for me on Puma "3.11.4":

Capybara.configure do |config|
  config.server = :puma, { Silent: true }
end

Thanks @swrobel.

elia added a commit to nebulab/solidus that referenced this issue Jan 23, 2020
Puma is taken as the default rack server, but until
rspec/rspec-rails#1897 is solved we should
stick to the proposed workaround.
elia added a commit to nebulab/solidus that referenced this issue Jan 23, 2020
Puma is taken as the default rack server, but until
rspec/rspec-rails#1897 is solved we should
stick to the proposed workaround.
@benoittgt
Copy link
Member

Closed by #2289

stevenday pushed a commit to openownership/register that referenced this issue Mar 19, 2020
See rspec/rspec-rails#1897 - this should be
silenced already but something in Rails 5.2 causes it not to be.

Without this we see the Puma startup message in our spec output.
stevenday pushed a commit to openownership/register that referenced this issue Mar 20, 2020
See rspec/rspec-rails#1897 - this should be
silenced already but something in Rails 5.2 causes it not to be.

Without this we see the Puma startup message in our spec output.
Cruikshanks added a commit to DEFRA/sroc-tcm-admin that referenced this issue Nov 12, 2020
Whenever we run `bundle exec rails test` at somepoint we see this in the test output

```
Capybara starting Puma...
* Version 5.0.4 , codename: Spoony Bard
* Min threads: 0, max threads: 4
/home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil
* Listening on http://127.0.0.1:37836
```

It seems to be triggered by hitting a test that requires javascript. That and the solution I actually found on an [RSpec issue](rspec/rspec-rails#1897).

We still get the following error appear

```
/home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil
```

But we are hoping this will be fixed in the next version of Puma.
Cruikshanks added a commit to DEFRA/sroc-tcm-admin that referenced this issue Nov 12, 2020
https://blog.travis-ci.com/2020-11-02-travis-ci-new-billing
https://www.jeffgeerling.com/blog/2020/travis-cis-new-pricing-plan-threw-wrench-my-open-source-works

On Nov 2 Travis-CI introduced a new pricing model for their free tier offering. Those on this tier would now be limited to 1000 build minutes a month. This would start to be rolled out across accounts imminently. Defra's seems to have been updated November 9 because by the end of the day all builds stopped. When you went to Travis-CI a message was shown stating

> Builds have been temporarily disabled for private and public repositories due to a negative credit balance. Please go to the Plan page to replenish your credit balance.

It's going to take some time to decide and agree whether we will move to a paid-for option, or choose to start rolling our own. We don't like the idea of having no automated CI during this unknown period. A number of people caught up in this change have suggested [GitHub Actions](https://docs.github.com/en/free-pro-team@latest/actions) as an alternative.

So this change moves the project from Travis to GitHub to handle our CI

Because of the dependence on selenium based tests we also had to make a number of other changes

** Update chrome headless capybara driver code

We spent ages trying to get the selenium based tests to run in GitHub Actions. All our initial efforts were focused on thinking there was something we needed to do in the environment. Start xvfb, set special chromedriver settings, grab the latest chromedriver etc. This was even though lots of posts noted that this was no longer needed as GitHub's `ubuntu-latest` build comes with tools like these pre-installed.

We then started looking at how the driver was being registered. It turns out that a recent update to the Capybara gem required us to update how we were registering the driver. Switching to the pre-registered `:selenium_chrome_headless` got us from no passing selenium tests to all but 4.

So we then reviewed the [source code](https://github.com/teamcapybara/capybara/blob/master/lib/capybara/registrations/drivers.rb#L27) for what [team capybara](https://github.com/teamcapybara) were doing. By combining that with existing args we were using that again lots of posts advised, we finally got it working!

** Remove mini-test reporters

Whilst the progress bar format is nice, its unnecessary. Plus it does not work well with the GitHub action.

** Silence puma for Capybara tests

Whenever we run `bundle exec rails test` at some point we see this in the test output

```
Capybara starting Puma...
* Version 5.0.4 , codename: Spoony Bard
* Min threads: 0, max threads: 4
/home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil
* Listening on http://127.0.0.1:37836
```

It seems to be triggered by hitting a test that requires javascript. That and the solution I actually found on an [RSpec issue](rspec/rspec-rails#1897).

We still get the following error appearing

```
/home/vagrant/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/gems/puma-5.0.4/lib/puma/server.rb:94: warning: deprecated Object#=~ is called on Proc; it always returns nil
```

But we are hoping this will be fixed in the next version of Puma.
Web-Go-To added a commit to Web-Go-To/rails_suspenders that referenced this issue Mar 23, 2023
When Capybara starts the first JavaScript spec of a run, it starts Puma
and prints out the Puma startup messages:

    Capybara starting Puma...
    * Version 3.12.1 , codename: Llamas in Pajamas
    * Min threads: 0, max threads: 4
    * Listening on tcp://127.0.0.1:62516

By setting `Silent: true`, we can prevent those messages from being
printed.

A bit of background: rspec/rspec-rails#1897

Proof that Capybara uses Puma as its default server: https://github.com/teamcapybara/capybara/blob/3.24.0/lib/capybara.rb#L247-L249
ConnorHerron19 added a commit to ConnorHerron19/rails_suspenders that referenced this issue Mar 23, 2023
When Capybara starts the first JavaScript spec of a run, it starts Puma
and prints out the Puma startup messages:

    Capybara starting Puma...
    * Version 3.12.1 , codename: Llamas in Pajamas
    * Min threads: 0, max threads: 4
    * Listening on tcp://127.0.0.1:62516

By setting `Silent: true`, we can prevent those messages from being
printed.

A bit of background: rspec/rspec-rails#1897

Proof that Capybara uses Puma as its default server: https://github.com/teamcapybara/capybara/blob/3.24.0/lib/capybara.rb#L247-L249
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests