aboutsummaryrefslogtreecommitdiffstats
path: root/railties/test/commands/server_test.rb
Commit message (Collapse)AuthorAgeFilesLines
* Revert "Remove deprecated `server` argument from the rails server command"yuuji.yaginuma2019-01-181-0/+4
| | | | | | This reverts commit fa791fb8e2a718b5d0430c7ca5a454678dfc192d. Reason: `server` argument was deprecated in Rails 6.0. Ref: #32058.
* Remove deprecated `server` argument from the rails server commandRafael Mendonça França2019-01-171-4/+0
|
* Do not show suggestion message when not exist suggestionyuuji.yaginuma2018-12-291-0/+6
| | | | | | | | | | | | | | | | | | **before** ``` $ ./bin/rails g g Could not find generator 'g'. Maybe you meant nil? Run `rails generate --help` for more options. ``` **after** ``` $ ./bin/rails g g Could not find generator 'g'. Run `rails generate --help` for more options. ```
* Use string for arguments in server testyuuji.yaginuma2018-12-131-2/+2
| | | | | | | | | | | When actually execute from the command, the value of ARGV is passed to the server. So they are String. So let's use the same type in the test. Also, this removes the following warning in Ruby 2.6. ``` lib/rails/commands/server/server_command.rb:195: warning: deprecated Object#=~ is called on Integer; it always returns nil ```
* Allow to explicitly specify whether to output Rails' log to stdoutMarkus Doits2018-07-081-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | Before Rails' logger output is mirrored to std out if: * environment is development and * the process is not daemonized It was not possible to change that behaviour, e.g. to disable log output in that case or enable it in other cases. Now you can explicitly disable or enable output with the new command line switch `--log-to-stdout`, regardless of any other circumstances. ``` // enable output in production rails server -e production --log-to-stdout // disable output in development rails server -e development --no-log-to-stdout ``` Enabling output when daemonized still makes no sense (since tty is detached), but this is ignored for now. If the command line flag is not specified, old behaviour still applies, so this change is completely backward compatible.
* Don't show unneeded deprecation warning on server restart.Kasper Timm Hansen2018-07-071-3/+2
| | | | | | | | | | | | | | | | | If booting a server via `rails s -u puma`, we'd convert the option to a `using` positional. When using `rails restart` our `restart_command` would the option converted to the using positional and put that in the restart command. Thus we'd show users deprecation warnings for our own code. Fix that by converting a passed positional to an option instead. Also: fix initialize method signature. The local_options are an array, not a hash. But don't even bother assigning defaults as Thor passes them in.
* Deprecate support for using `HOST` environment to specify server IP (#32540)Yuji Yaginuma2018-04-161-1/+15
| | | | | | | | | | | | At SuSE, `$HOST` is set by default and is equal to `$HOSTNAME`. https://www.suse.com/documentation/sled11/book_sle_admin/data/sec_adm_variables.html Therefore, by default, it binds to hostname instead of `localhost`. This seems not to be appropriate as default behavior. In order to avoid the name of the environment variable being used, I changed the environment variable from `HOST` to `BINDING`. Fixes #29516.
* Use `did_you_mean` spell checker for option suggestionsGenadi Samokovarov2018-03-231-1/+1
| | | | | | | | | | | Now that we require Ruby over `2.3`, we can replace the current suggestion methods we have with tooling from the `did_you_mean` gem. There is a small user visible change and this is that we now offer a single suggestion for misspelled options. We are suggesting fixes during generator invocation and during a mistyped rails server rack handler. In both cases, if we don't make a proper prediction on the first match, we won't do so in the second or third one, so in my mind, this is okay.
* Fix "NameError: undefined local variable or method `host'"yuuji.yaginuma2018-03-051-0/+6
| | | | The `host` and `port` can't use this context.
* Introduce explicit rails server handler optionGenadi Samokovarov2018-03-041-4/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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. ```
* Fix test name for daemon option testyuuji.yaginuma2017-10-141-2/+2
| | | | | | | In this test file, "server option" refers to the server used to start Rails(e.g. `puma`, `thin`). But this test, "server option" is not specified. Therefore, I think that it is incorrect that `server_option` is included in the test name.
* Added test case for starting rails with daemon option, this should set the ↵Pierre Hedkvist2017-10-131-0/+12
| | | | option[:daemonize] to true, otherwise the option[:daemonize] will be set to false
* Implement H2 Early Hints for Railseileencodes2017-10-041-0/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When puma/puma#1403 is merged Puma will support the Early Hints status code for sending assets before a request has finished. While the Early Hints spec is still in draft, this PR prepares Rails to allowing this status code. If the proxy server supports Early Hints, it will send H2 pushes to the client. This PR adds a method for setting Early Hints Link headers via Rails, and also automatically sends Early Hints if supported from the `stylesheet_link_tag` and the `javascript_include_tag`. Once puma supports Early Hints the `--early-hints` argument can be passed to the server to enable this or set in the puma config with `early_hints(true)`. Note that for Early Hints to work in the browser the requirements are 1) a proxy that can handle H2, and 2) HTTPS. To start the server with Early Hints enabled pass `--early-hints` to `rails s`. This has been verified to work with h2o, Puma, and Rails with Chrome. The commit adds a new option to the rails server to enable early hints for Puma. Early Hints spec: https://tools.ietf.org/html/draft-ietf-httpbis-early-hints-04 [Eileen M. Uchitelle, Aaron Patterson]
* Make `restart` and `dev:cache` tasks work when customizing pid file pathyuuji.yaginuma2017-08-211-1/+1
| | | | | | | | | | Originally, it hard-coded pid file path. It can not be removed when customizing pid file path. But rake task can not get pid file path. Therefore, do not remove file in rake task, makes it possible to judge whether it is restart from the argument of the command and removes the file in server command. Fixes #29306
* Adding frozen_string_literal pragma to Railties.Pat Allan2017-08-141-0/+2
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Correctly set user_supplied_options when there is no whitespace in option ↵yuuji.yaginuma2017-05-241-0/+6
| | | | | | | | | | specification Current `user_supplied_options` method can not set the value correctly if there is no space between option and value (e.g., `-p9000`). This makes it possible to set the value correctly in the case like the above. Fixes #29138
* CLI arg `--port` has precedence over env `PORT`.koshigoe2017-05-011-0/+12
|
* CLI arg "host" has precedence over ENV var "host"Jon Moss2017-03-211-0/+8
| | | | | | | This is a regression from when the server command switched to its own argument parser, as opposed to Rack's. Rack's argument parser, when provided with a "host" argument, gives that value precedence over environment variables.
* Set correct host except development environmentyuuji.yaginuma2017-02-271-0/+18
| | | | | | | | Currently `localhost` is used for the default host in all environments. But up to Rails 5.0, `0.0.0.0` is used except for development. So fixed to use the same value as 5.0. Fixes #28184
* [close #24435] Send user_supplied_options to serverschneems2017-02-241-0/+8
| | | | | | | | | | | | | | | | | | Currently when Puma gets a `:Port` it doesn't know if it is Rails' default port or if it is one that is specified by a user. Because of this it assumes that the port passed in is always a user defined port and therefor 3000 always "wins" even if you specify `port` inside of the `config/puma.rb` file when booting your server with `rails s`. The fix is to record the options that are explicitly passed in from the user and pass those to the Puma server (or all servers really). Puma then has enough information to know when `:Port` is the default and when it is user defined. I went ahead and did this for all values rails server exposes as server side options for completeness. The hardest thing was converting the input say `-p` or `--port` into the appropriate "name", in this case `Port`. There may be a more straightforward way to do this with Thor, but I'm not an expert here. Move logic for parsing user options to method Better variable name for iteration Explicitly test `--port` user input ✂️ Update array if environment variables are used
* improve server default options testyuuji.yaginuma2017-01-091-3/+3
| | | | | | | This test was added in 221b4ae. 221b4ae modified to return the same result even if `Rails::Server#default_options` is called more than once. Therefore, also use `Rails::Server#default_options` instead of `ServerCommand#default_options` in test.
* Merge branch 'master' into fix_26964Kasper Timm Hansen2016-12-291-1/+1
|\
| * "Use assert_nil if expecting nil. This will fail in minitest 6."Akira Matsuda2016-12-251-1/+1
| |
* | use Thor option parser in server commands parseyuuji.yaginuma2016-12-241-36/+43
|/ | | | | | | | | | The `ServerCommand` inherits Thor, but currently does not use Thor option parser. Therefore, if leave the argument of Thor as it is, it becomes an error by the argument checking of Thor. To avoid it, to use the Thor option parser instead of reimplementing it. Fixes #26964
* Fix server command tests.Kasper Timm Hansen2016-09-251-1/+2
|
* applies new string literal convention in railties/testXavier Noria2016-08-061-15/+15
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Use the HOST environment variable for rails server #25677Evgeny Vlasenko2016-07-051-0/+7
|
* Fix rails restart issue with PumaPrathamesh Sonpatki2016-03-301-0/+14
| | | | | | | | | | | | | | | - We need to pass the restart command to Puma so that it will use it while restarting the server. - Also made sure that all the options passed by user while starting the server are used in the generated restart command so that they will be used while restarting the server. - Besides that we need to remove the server.pid file for the previous running server because otherwise Rack complains about it's presence. - We don't care if the server.pid file does not exist. We only want to delete it if it exists. - This also requires some changes on Puma side which are being tracked here - https://github.com/puma/puma/pull/936. - Fixes #23910.
* changed default value of `caching` option to `nil`yuuji.yaginuma2016-03-211-1/+2
| | | | | | | The default is that's false, caching even if you do not specify the caching option is determined not to use, and `tmp/caching-dev.txt` will be deleted. If it is this, regardless of whether or not there is `tmp/caching-dev.txt`, be sure to order would be necessary to specify the caching option, I think that in than good to so as not to do anything by default.
* Avoid multiple default paths to server.pid fileTawan Sierek2016-01-161-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | Fix bug (#22811) that occurs when rails server is started in daemon mode and optional path to the `server.pid` file is omitted. Store default path in a constant instead of evaluating it multiple time using `File.expand_path`. The bug in detail: The server startup procedure crashes, since it tries to open a file at `/tmp/pids/server.pid` instead of `<path to project>/tmp/pids/server.pid`. This bug was introduced in 51211a94bd when Rack was upgraded from version 1.x to 2.x. Since version 2.x, Rack does not memoize the options hash [1], and as a consequence `Rails::Server#default_options` will be evaluated multiple times. The hash returned by `Rails::Server#default_options` holds the default path to the `server.pid` file. The path is generated with the method `File.expand_path`. However, the return value of this method depends on the current working directory [2], which changes once `Process.daemon` is invoked by `Rack::Server#daemonize_app` and the process is detached from the current shell. Close #22811 [1]https://git.io/vzen2 [2]http://ruby-doc.org/core-2.1.5/File.html#method-c-expand_path
* Use the PORT environment variable for rails serverDavid Cornu2015-08-181-0/+7
|
* Add rake dev:cache task to enable dev mode caching.Chuck Callebs2015-08-041-0/+16
| | | | | | | | | | | | | | | | Taken from @Sonopa's commits on PR #19091. Add support for dev caching via "rails s" flags. Implement suggestions from @kaspth. Remove temporary cache file if server does not have flags. Break at 80 characters in railties/CHANGELOG.md Remove ability to disable cache based on server options. Add more comprehensive options: --dev-caching / --no-dev-caching
* Revert "Merge pull request #19404 from dmathieu/remove_rack_env"Jeremy Kemper2015-03-201-19/+44
| | | | | | | Preserving RACK_ENV behavior. This reverts commit 7bdc7635b885e473f6a577264fd8efad1c02174f, reversing changes made to 45786be516e13d55a1fca9a4abaddd5781209103.
* don't fallback to RACK_ENV when RAILS_ENV is not presentDamien Mathieu2015-03-191-44/+19
|
* Make logging to stdout work again with implicit `development` envMarc Schütz2013-10-131-12/+48
|
* Only output Server logs in Developmentschneems2013-09-221-0/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Refactor tests that switch RAILS_ENV and RACK_ENVCarlos Antonio da Silva2012-12-061-14/+10
| | | | | | | | | | | | This cleanup aims to fix a build failure: https://travis-ci.org/rails/rails/jobs/3515951/#L482 Since travis always have both ENV vars set to "test", a test is failing where it's expected to output the default env "development", but "test" is the result due to RACK_ENV being set when we expect it to not be. By cleaning this duplication we ensure that changing any of these env variables will pick the right expected value.
* Add ENV['RACK_ENV'] support to rake runner/console/server.kennyj2012-12-061-0/+20
|
* Remove support for rails server RAILS_ENV=env-nameSam Oliver2012-05-301-2/+2
|
* fix rails server support of RAILS_ENV variableschneems2012-03-201-0/+26
When launching rails server from the command line with a rails environment specified such as `rails server RAILS_ENV=production` an error would occur since rails will try to use `RAILS_ENV=production` as it's server. When launching rails with a specified server such as thin `rails server thin RAILS_ENV=production` no error will be thrown, but rails will not start up in the specified environment. This fixes both of those cases