| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|\
| |
| | |
Turn on performance based cops
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Use attr_reader/attr_writer instead of methods
method is 12% slower
Use flat_map over map.flatten(1)
flatten is 66% slower
Use hash[]= instead of hash.merge! with single arguments
merge! is 166% slower
See https://github.com/rails/rails/pull/32337 for more conversation
|
|\ \
| |/
|/|
| |
| | |
albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
|
| |
| |
| |
| |
| | |
With this commit, rails commands usage instructions display now +rails+
instead of +bin/rails+ within their recommendations.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As discussed in #33203 rails command already looks for, and runs,
bin/rails if it is present.
We were mixing recommendations within guides and USAGE guidelines,
in some files we recommended using rails, in others bin/rails and
in some cases we even had both options mixed together.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
| |
* Get rid of map and replace it with a multiplication of "\n" to generate document with multiple line preceding the annotation
* Reduce number from 1000 to 100 since it achieves the same goal
* Only keep one test for the multiple lines document since it's unecessary to test multiple times
* Update some language in tests names to make it clearer what we are testing
|
|\
| |
| | |
Adds `Rails::Command::NotesCommand` and makes `rake notes` use it under the hood
|
| |
| |
| |
| |
| | |
* Require the application and environnement in the notes command in order to load the config files
* Adds tests for both register_directories and register_extensions added to a config file
|
| |
| |
| |
| |
| |
| |
| |
| | |
* It is called with `rails notes`
* It defaults to displaying [OPTIMIZE, FIXME and TODO] annotations
* It accepts custom annotations by using `rails notes -a CUSTOM_ANNOTATION OTHER_ANNOTATION`
* It defaults to look for annotations in [app config db lib test] as dictated by SourceAnnotationExtractor
* It supports ENV["SOURCE_ANNOTATION_DIRECTORIES"] but adds a deprecation warning and recommends using register_directories instead
|
|/
|
|
| |
is specified
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We end up with:
```
Usage:
bin/rails routes [options]
Options:
-c, [--controller=CONTROLLER] # Filter by a specific controller, e.g. PostsController or Admin::PostsController.
-g, [--grep=GREP] # Grep routes by a specific pattern.
-E, [--expanded], [--no-expanded] # Print routes expanded vertically with parts explained.
```
which does miss the bit about routes being printed in order.
Also:
* Renames options to ease help output readability, then clarifies each option.
* Fixes a bunch of indentation.
|
|\
| |
| | |
Draw line of a route name to the end of row console on `rails routes --expanded`
|
| |
| |
| |
| |
| |
| |
| | |
In order to get width of console use `IO::console_size`,
See https://ruby-doc.org/stdlib-2.4.1/libdoc/io/console/rdoc/IO.html#method-c-console_size
Related to #32130
|
|/
|
|
| |
Related to 6bd33d66dde015a55912af20b469788ba20ddb4e
|
|
|
|
| |
The `host` and `port` can't use this context.
|
|\
| |
| | |
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.
```
|
|/ |
|
|
|
|
|
|
| |
* Remove unused require
* Remove redundant `test`
* Change `rake` to `rails`
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When using rails routes with small terminal or complicated routes it can be
very difficult to understand where is the element listed in header. psql
had the same issue, that's why they created "expanded mode" you can
switch using `\x` or by starting psql with
```
-x
--expanded
Turn on the expanded table formatting mode. This is equivalent to the \x command.
```
The output is similar to one implemented here for rails routes:
db_user-# \du
List of roles
-[ RECORD 1 ]----------------------------------------------
Role name | super
Attributes | Superuser, Create role, Create DB
Member of | {}
-[ RECORD 2 ]----------------------------------------------
Role name | role
Attributes | Superuser, Create role, Create DB, Replication
Member of | {}
|
|
|
|
|
|
| |
After a discussion with matthewd. It was mentioned that rake tasks need
to be moved to rails command.
See: https://github.com/rails/rails/issues/32117
|
|
|
| |
Fixes #31917
|
| |
|
|
|
|
|
|
|
|
|
| |
To prevent errors from being raise in environments where credentials
is unnecessary.
Context: https://github.com/rails/rails/issues/31283#issuecomment-348801489
Fixes #31283
|
|
|
|
| |
Fixes #31286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To edit/show encrypted file:
```
bin/rails encrypted:edit config/staging_tokens.yml.enc
bin/rails encrypted:edit config/staging_tokens.yml.enc --key config/staging.key
bin/rails encrypted:show config/staging_tokens.yml.enc
```
Also provides a backing Rails.application.encrypted API for Ruby access:
```ruby
Rails.application.encrypted("config/staging_tokens.yml.enc").read
Rails.application.encrypted("config/staging_tokens.yml.enc").config
Rails.application.encrypted("config/staging_tokens.yml.enc", key: "config/staging.key")
```
|
|
|
|
|
|
|
|
| |
Allow edits of existing encrypted secrets generated on Rails 5.1,
but refer to credentials when attempting to setup.
This also removes the need for any of the setup code, so the
generator can be ripped out altogether.
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
option[:daemonize] to true, otherwise the option[:daemonize] will be set to false
|
|
|
|
|
| |
If need a parse result of arguments, can obtain it by creating
an instance of the command.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
|
| |
For gitignore generated by `rails new`, key with a leading slash is specified.
https://github.com/rails/rails/blob/69f976b859cae7f9d050152103da018b7f5dda6d/railties/lib/rails/generators/rails/app/templates/gitignore#L11
Therefore, when executing `credentials:edit`, also need leading slack.
In order to avoid such a difference, fixed to use same method for
`rails new` and `credentials:edit`.
|
|
|
|
|
| |
While this avoids shell argument parsing, we still pass through
everything in our stack.
|
|
|
|
|
|
|
|
|
| |
Without this, `dbconsole` raises an error as follwing:
```
RuntimeError: can't modify frozen String
railties/lib/rails/commands/dbconsole/dbconsole_command.rb:79:in `start'
```
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
| |
Running the `console` and `dbconsole` commands with a regular argument
as the environment's name automatically expand it to match an existing
environment (e.g. dev for development).
This feature wasn't available using the `--environment` (a.k.a `-e`)
option.
|
|
|
|
|
|
| |
People should rather rely on the `-e` or `--environment` options to
specify in which environment they want to work. This will allow us
to specify the connection to pick as a regular argument in the future.
|
|
|
|
|
|
|
|
|
|
|
| |
Since 0a4f6009, it's possible to specify a 3-level database
configuration to gather connections by environment.
The `dbconsole` command will try to look for a database configuration
which points to the current environment but with such flavour, the
environment key is flushed out so let's add the ability to specify
the connection and pick `primary` by default to be consistent with
Active Record.
|
|
|
|
|
|
|
|
|
|
|
| |
When secrets confirmed with the `secrets:edit` command, `secrets.yml.enc`
will change without updating the secrets.
Therefore, even if only want to check secrets, the difference will come
out. This is a little inconvenient.
In order to solve this problem, added the `secrets:show` command.
If just want to check secrets, no difference will occur use this command.
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|