| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This reverts commit fa791fb8e2a718b5d0430c7ca5a454678dfc192d.
Reason: `server` argument was deprecated in Rails 6.0. Ref: #32058.
|
| |
|
|
|
|
| |
as argument of `run`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
**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.
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rails 6.0 will support Ruby 2.4.1 or higher
`# frozen_string_literal: true` magic comment is enough to make string object frozen.
This magic comment is enabled by `Style/FrozenStringLiteralComment` cop.
* Exclude these files not to auto correct false positive `Regexp#freeze`
- 'actionpack/lib/action_dispatch/journey/router/utils.rb'
- 'activerecord/lib/active_record/connection_adapters/sqlite3_adapter.rb'
It has been fixed by https://github.com/rubocop-hq/rubocop/pull/6333
Once the newer version of RuboCop released and available at Code Climate these exclude entries should be removed.
* Replace `String#freeze` with `String#-@` manually if explicit frozen string objects are required
- 'actionpack/test/controller/test_case_test.rb'
- 'activemodel/test/cases/type/string_test.rb'
- 'activesupport/lib/active_support/core_ext/string/strip.rb'
- 'activesupport/test/core_ext/string_ext_test.rb'
- 'railties/test/generators/actions_test.rb'
|
| |
|
|\
| |
| | |
rails server: Allow to explicitly specify whether to output Rails's log to stdout
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
| |
We prefer double quotes over single quotes.
Fixes:
```
railties/lib/rails/commands/server/server_command.rb:279:39:
C: Style/StringLiterals: Prefer double-quoted strings unless you need
single quotes to avoi d extra backslashes for escaping.
original_options.concat [ '-u', using ]
```
Related to 161ed37d7120e1f391eed19e49a3390e53e4fe91
|
|
|
|
|
|
|
|
| |
Our restart_command would pass in `--restart` which means
that if the @original_options already contains --restart
it would keep getting another --restart appended.
Nothing here that would break the bank, but just a nicety.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
Ref:
https://github.com/rails/rails/commit/654704247eba742e139cfaa8d1385f13605d9e12
Before the commit we had a restart_command in Rails::Server. But after
there's another one in Rails::ServerCommand. The command version of the
method is the right one as it's used in server_options.
Give the leftover method the boot.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Mixing strings and symbols seems aesthetically less than ideal.
We can also use underscores just fine. Thor converts them to dashes
for the CLI and it makes access in Ruby code nicer.
Here's the `server --help` output after this change:
```
Usage:
rails server [thin/puma/webrick] [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.
```
See? Quite dashing ✨
|
|
|
|
| |
`optparse` is unused since #26977.
|
|
|
|
|
| |
Since #32289, `Spellchecker.suggest` returns only one value, multiple
suggestions not output.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, `Exiting` is showed during server startup.
```
./bin/rails s
=> Booting Puma
=> Rails 6.0.0.alpha application starting in development
=> Run `rails server --help` for more startup options
Exiting
Puma starting in single mode...
* Version 3.11.2 (ruby 2.5.0-p0), codename: Love Song
```
This is because processing at server stop is passed as a block, and
`Rack::Serve#start` receives a block and executes it during startup processing.
https://github.com/rack/rack/blob/50db1ffdf8b98503fb7c6e6648622b5d7d78d58e/lib/rack/server.rb#L258
In order to avoid this, stop processing is passed as argument.
|
|
|
|
| |
The `host` and `port` can't use this context.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
```
|
|
|
|
| |
start the Rails server
|
|
|
|
| |
This basically reverts 618268b4b9382f4bcf004a945fe2d85c0bd03e32
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
| |
Since Rails 4.0, `config.ru` generated by default uses instances of
`Rails.application`. Therefore, I think that it is good to deprecate
the old behavior.
Related: #9669
|
|
|
|
|
|
|
|
|
|
|
| |
Puma has its own configuration file(e.g. `config/puma.rb`).
Can define a port and a URL to bind in the configuration file. Therefore,
on Rails side, can not grasp which URI to bind finally.
Because of that, it may show a URL different from the actually bound
URL, so I think that it is better not to show it.
Fixes #29880
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Ref: https://github.com/rails/rails/blob/master/railties/lib/rails/commands/server/server_command.rb#L194
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Currently, all rails commands can be executed in engine,
but `server`, `console`, `dbconsole` and `runner` do not work.
This make all rails commands work in engine.
Related to #22588
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
They're just barren on the site and confure more than guide, instead
rely on the built in --help to guide users.
|
|
|
|
| |
`mongrel` was removed in #26408. But have back accidentally in #26414.
|
| |
|
|
|
|
| |
Prescribed some review fixes for myself!
|
|
|