1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/railties/test/commands/server_test.rb

322 lines
8.7 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
require "isolation/abstract_unit"
require "env_helpers"
2016-09-18 14:10:27 -04:00
require "rails/command"
require "rails/commands/server/server_command"
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
class Rails::Command::ServerCommandTest < ActiveSupport::TestCase
include EnvHelpers
def test_environment_with_server_option
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
args = ["-u", "thin", "-e", "production"]
options = parse_arguments(args)
assert_equal "production", options[:environment]
assert_equal "thin", options[:server]
end
def test_environment_without_server_option
args = ["-e", "production"]
options = parse_arguments(args)
assert_equal "production", options[:environment]
assert_nil options[:server]
end
def test_environment_option_is_properly_expanded
args = ["-e", "prod"]
options = parse_arguments(args)
assert_equal "production", options[:environment]
end
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
def test_explicit_using_option
args = ["-u", "thin"]
options = parse_arguments(args)
assert_equal "thin", options[:server]
end
def test_using_server_mistype
assert_match(/Could not find server "tin". Maybe you meant "thin"?/, run_command("--using", "tin"))
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
end
def test_using_server_mistype_without_suggestion
output = run_command("--using", "t")
assert_match(/Could not find server "t"/, output)
assert_no_match(/Maybe you meant/, output)
end
def test_using_positional_argument_deprecation
assert_match(/DEPRECATION WARNING/, run_command("tin"))
end
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
def test_using_known_server_that_isnt_in_the_gemfile
assert_match(/Could not load server "unicorn". Maybe you need to the add it to the Gemfile/, run_command("-u", "unicorn"))
end
def test_daemon_with_option
args = ["-d"]
options = parse_arguments(args)
assert_equal true, options[:daemonize]
end
def test_daemon_without_option
args = []
options = parse_arguments(args)
assert_equal false, options[:daemonize]
end
def test_server_option_without_environment
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
args = ["-u", "thin"]
with_rack_env nil do
with_rails_env nil do
options = parse_arguments(args)
assert_equal "development", options[:environment]
assert_equal "thin", options[:server]
end
end
end
def test_environment_with_rails_env
with_rack_env nil do
with_rails_env "production" do
options = parse_arguments
assert_equal "production", options[:environment]
end
end
end
def test_environment_with_rack_env
with_rails_env nil do
with_rack_env "production" do
options = parse_arguments
assert_equal "production", options[:environment]
end
end
end
def test_environment_with_port
switch_env "PORT", "1234" do
options = parse_arguments
assert_equal 1234, options[:Port]
end
end
def test_environment_with_host
switch_env "HOST", "1.2.3.4" do
assert_deprecated do
options = parse_arguments
assert_equal "1.2.3.4", options[:Host]
end
end
end
def test_environment_with_binding
switch_env "BINDING", "1.2.3.4" do
options = parse_arguments
assert_equal "1.2.3.4", options[:Host]
end
end
def test_environment_with_pidfile
switch_env "PIDFILE", "/tmp/rails.pid" do
options = parse_arguments
assert_equal "/tmp/rails.pid", options[:pid]
end
end
def test_caching_without_option
args = []
options = parse_arguments(args)
2016-12-29 14:09:43 -05:00
assert_nil options[:caching]
end
def test_caching_with_option
args = ["--dev-caching"]
options = parse_arguments(args)
assert_equal true, options[:caching]
args = ["--no-dev-caching"]
options = parse_arguments(args)
assert_equal false, options[:caching]
end
def test_early_hints_with_option
args = ["--early-hints"]
options = parse_arguments(args)
assert_equal true, options[:early_hints]
end
def test_early_hints_is_nil_by_default
args = []
options = parse_arguments(args)
assert_nil options[:early_hints]
end
def test_log_stdout
with_rack_env nil do
with_rails_env nil do
args = []
options = parse_arguments(args)
assert_equal true, options[:log_stdout]
args = ["-e", "development"]
options = parse_arguments(args)
assert_equal true, options[:log_stdout]
args = ["-e", "development", "-d"]
options = parse_arguments(args)
assert_equal false, options[:log_stdout]
args = ["-e", "production"]
options = parse_arguments(args)
assert_equal false, options[:log_stdout]
args = ["-e", "development", "--no-log-to-stdout"]
options = parse_arguments(args)
assert_equal false, options[:log_stdout]
args = ["-e", "production", "--log-to-stdout"]
options = parse_arguments(args)
assert_equal true, options[:log_stdout]
with_rack_env "development" do
args = []
options = parse_arguments(args)
assert_equal true, options[:log_stdout]
end
with_rack_env "production" do
args = []
options = parse_arguments(args)
assert_equal false, options[:log_stdout]
end
with_rails_env "development" do
args = []
options = parse_arguments(args)
assert_equal true, options[:log_stdout]
end
with_rails_env "production" do
args = []
options = parse_arguments(args)
assert_equal false, options[:log_stdout]
end
end
end
Only output Server logs in Development Right now when you start a server via `rails s`, the logger gets extended so that it logs to the file system and also to stdout. This extension behavior is not "intelligent" and if the default logger is already set to output to stdout, then the contents will be received twice. To capture logs in accordance with http://www.12factor.net/logs some platforms require the logs to be sent to standard out. If a logger is set to stdout, and the server is started using `rails server` instead of another method (i.e. `thin start` etc.) then the app will produce double logs. This PR fixes the issue by only extending the logger to standard out in the development environment. So that in production you don't get double logs like this: ``` ActionView::Template::Error (wrong number of arguments (5 for 4)): 1: <% lang_index = 0 %> 2: <div class="row"> 3: <ul class="nav nav-tabs nav-stacked span2" data-tabs="tabs" id="repo-tabs"> 4: <% repos.group_by(&:language).each do |lang, repos| %> 5: <% unless lang == nil %> 6: <li><a href="#<%= "#{lang.parameterize}#{lang.hash}" %>" data-toggle="tab"><%= lang %></a></li> 7: <% end -%> app/views/shared/_repos.html.erb:4:in `_app_views_shared__repos_html_erb___1685450633638247395_70300668607000' app/views/pages/index.html.erb:13:in `_app_views_pages_index_html_erb__2084723628308867770_70300687584880' ActionView::Template::Error (wrong number of arguments (5 for 4)): 1: <% lang_index = 0 %> 2: <div class="row"> 3: <ul class="nav nav-tabs nav-stacked span2" data-tabs="tabs" id="repo-tabs"> 4: <% repos.group_by(&:language).each do |lang, repos| %> 5: <% unless lang == nil %> 6: <li><a href="#<%= "#{lang.parameterize}#{lang.hash}" %>" data-toggle="tab"><%= lang %></a></li> 7: <% end -%> app/views/shared/_repos.html.erb:4:in `_app_views_shared__repos_html_erb___1685450633638247395_70300668607000' app/views/pages/index.html.erb:13:in `_app_views_pages_index_html_erb__2084723628308867770_70300687584880' ``` ATP Railties. Opened against master in favor of #10999
2013-06-18 16:24:00 -04:00
end
def test_host
with_rails_env "development" do
options = parse_arguments([])
assert_equal "localhost", options[:Host]
end
with_rails_env "production" do
options = parse_arguments([])
assert_equal "0.0.0.0", options[:Host]
end
with_rails_env "development" do
args = ["-b", "127.0.0.1"]
options = parse_arguments(args)
assert_equal "127.0.0.1", options[:Host]
end
end
def test_argument_precedence_over_environment_variable
switch_env "PORT", "1234" do
args = ["-p", "5678"]
options = parse_arguments(args)
assert_equal 5678, options[:Port]
end
switch_env "PORT", "1234" do
args = ["-p", "3000"]
options = parse_arguments(args)
assert_equal 3000, options[:Port]
end
switch_env "BINDING", "1.2.3.4" do
args = ["-b", "127.0.0.1"]
options = parse_arguments(args)
assert_equal "127.0.0.1", options[:Host]
end
switch_env "PIDFILE", "/tmp/rails.pid" do
args = ["-P", "/somewhere/else.pid"]
options = parse_arguments(args)
assert_equal "/somewhere/else.pid", options[:pid]
end
end
def test_records_user_supplied_options
server_options = parse_arguments(["-p", "3001"])
assert_equal [:Port], server_options[:user_supplied_options]
server_options = parse_arguments(["--port", "3001"])
assert_equal [:Port], server_options[:user_supplied_options]
server_options = parse_arguments(["-p3001", "-C", "--binding", "127.0.0.1"])
assert_equal [:Port, :Host, :caching], server_options[:user_supplied_options]
server_options = parse_arguments(["--port=3001"])
assert_equal [:Port], server_options[:user_supplied_options]
switch_env "BINDING", "1.2.3.4" do
server_options = parse_arguments
assert_equal [:Host], server_options[:user_supplied_options]
end
switch_env "PORT", "3001" do
server_options = parse_arguments
assert_equal [:Port], server_options[:user_supplied_options]
end
switch_env "PIDFILE", "/tmp/server.pid" do
server_options = parse_arguments
assert_equal [:pid], server_options[:user_supplied_options]
end
end
def test_default_options
server = Rails::Server.new
old_default_options = server.default_options
Dir.chdir("..") do
assert_equal old_default_options, server.default_options
end
end
def test_restart_command_contains_customized_options
original_args = ARGV.dup
args = %w(-p 4567 -b 127.0.0.1 -c dummy_config.ru -d -e test -P tmp/server.pid -C)
ARGV.replace args
expected = "bin/rails server -p 4567 -b 127.0.0.1 -c dummy_config.ru -d -e test -P tmp/server.pid -C --restart"
assert_equal expected, parse_arguments(args)[:restart_cmd]
ensure
ARGV.replace original_args
end
def test_served_url
args = %w(-u webrick -b 127.0.0.1 -p 4567)
server = Rails::Server.new(parse_arguments(args))
assert_equal "http://127.0.0.1:4567", server.served_url
end
private
Introduce explicit rails server handler option I mistype `rails server production` instead of `rails server -e production` expecting to lunch a server in the production environment all the time. However, the signature of `rails server --help` is: ``` Usage: rails server [puma, thin etc] [options] ``` This means that the `production` argument is being interpreted as a Rack server handler like Puma, Thin or Unicorn. Should we argue for the `rails server production`? I'm not sure of the reasons, but the `rails console production` behavior was deprecated in: https://github.com/rails/rails/pull/29358, so parity with the existing `rails console production` usage may not hold anymore. In any case, this PR introduces an explicit option for the Rack servers configuration. The option is called `--using` (or `-u` for short) to avoid the `rails server --server` tantrum. The new interface of `rails server` is: ``` Usage: rails server [using] [options] Options: -p, [--port=port] # Runs Rails on the specified port - defaults to 3000. -b, [--binding=IP] # Binds Rails to the specified IP - defaults to 'localhost' in development and '0.0.0.0' in other environments'. -c, [--config=file] # Uses a custom rackup configuration. # Default: config.ru -d, [--daemon], [--no-daemon] # Runs server as a Daemon. -e, [--environment=name] # Specifies the environment to run this server under (development/test/production). -u, [--using=name] # Specifies the Rack server used to run the application (thin/puma/webrick). -P, [--pid=PID] # Specifies the PID file. # Default: tmp/pids/server.pid -C, [--dev-caching], [--no-dev-caching] # Specifies whether to perform caching in development. [--early-hints], [--no-early-hints] # Enables HTTP/2 early hints. ``` As a bonus, if you mistype the server to use, you'll get an auto-correction message: ``` $ rails s tin Could not find handler "tin". Maybe you meant "thin" or "cgi"? Run `rails server --help` for more options. ```
2018-02-19 13:31:56 -05:00
def run_command(*args)
build_app
rails "server", *args
ensure
teardown_app
end
def parse_arguments(args = [])
command = Rails::Command::ServerCommand.new([], args)
command.send(:extract_environment_option_from_argument)
command.server_options
end
end