-
-
Notifications
You must be signed in to change notification settings - Fork 1k
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
Comments
Same here, I fixed it with |
this configuration option should default to true. Do you have capybara and puma installed? |
I just ran into this as well. It looks like the first spec example, that runs with |
Can you try master? We've delayed loading system test integration which should eliminate this issue for you. |
Hi. I just gave 3.7.2 a shot and it's working great now. Thanks! |
@roberts1000 I upgraded to 3.7.2 as well, but still see the Puma log. Are you sure it wasn't something else? |
@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. |
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 config.before(:each, type: :system) do
driven_by :selenium, using: :headless_chrome
end |
Have you tried |
@JonRowe thought rspec-rails was supposed to set that, but where would be the preferred place to set that manually? |
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 |
Also had to add |
Try |
Unfortunately that didn't do it either |
The following in config.before(:all, type: :system) do
Capybara.server = :puma, { Silent: true }
end So weird... |
i'm getting this and none of these solutions seem to work. [rspec_junit_formatter is keeping us from upgrading rspec-rails] |
@rsl if you can't upgrade |
@JonRowe dang, well thanks for the answer |
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.
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:
We would do:
This seems a bit convoluted. Better would be for Rails to be changed so that simply requiring If you want to work around this issue in the meantime you can place the following in your
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. |
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 :) |
I don't believe it does. The code you pointed to runs too late. See my previous message for the full explanation. |
@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
then, provide us with a description of how to clone your application and reproduce the issue. Thanks :) |
It's slightly different, but maybe it's related. When I run RSpec (with capybara), I can trigger
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. |
@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 |
Followup note: Putting If I scroll up through the 8000 lines of "Loaded features" to notice there IS a ruby backtrace there, the final line is:
Which somehow made me realize maybe it was related to my trying to silence puma as above. The error is not entirely reliably reproducible, but somehow right now it is, and I have commented in-and-out the So that was apparently not the right solution. I really don't understand what's going on. Does anyone know the right way to keep puma log lines out of stdout in my test logs? Is everyone having this problem, with puma log lines in stdout? If everyone was having it, I'd think it would be a higher priority to fix... so maybe it's something special to my setup... but as far as I know I set up everything pretty darn standard for Rails 5.2, system tests, and capybara. Very confused and frustrated. |
It's possible it has nothing to do with this, heisenbugs are hard, and I don't really know how to read a C-level MRI crash report. In case this means anything to anyone: ruby 2.5.3p105 (2018-10-18 revision 65156) [x86_64-darwin16] console output |
Not everyone has this, its an ordering issue dependant on when puma is booted, the config option needs to happen before puma boots to take affect. I would paste that puma log to puma, it looks like a legit crash from a threading issue. |
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)
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? |
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 This is why the generated install drops a If all your specs are |
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.
This versions silences Puma logs during spec suite: rspec/rspec-rails#1897
This versions silences Puma logs during spec suite: rspec/rspec-rails#1897
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
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
This configuration on the
Thanks @swrobel. |
Puma is taken as the default rack server, but until rspec/rspec-rails#1897 is solved we should stick to the proposed workaround.
Puma is taken as the default rack server, but until rspec/rspec-rails#1897 is solved we should stick to the proposed workaround.
Closed by #2289 |
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.
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.
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.
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.
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
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.
Has anything changed in the rspec configuration?
(Screen capture in stackoverflow post)
The text was updated successfully, but these errors were encountered: