kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

Merge pull request #33229 from albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails

Browse source 
Prefer rails command over bin/rails
This commit is contained in:
Matthew Draper 2018-07-25 04:10:29 +09:30 committed by GitHub
commit ec387c6dd9
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
46 changed files with 301 additions and 304 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

2
actionpack/lib/action_dispatch/middleware/templates/rescues/invalid_statement.html.erb
View file

@ -11,7 +11,7 @@
<h2>
<%= h @exception.message %>
<% if @exception.message.match? %r{#{ActiveStorage::Blob.table_name}|#{ActiveStorage::Attachment.table_name}} %>
<br />To resolve this issue run: bin/rails active_storage:install
<br />To resolve this issue run: rails active_storage:install
<% end %>
</h2>

2
actionpack/lib/action_dispatch/middleware/templates/rescues/invalid_statement.text.erb
View file

@ -5,7 +5,7 @@
<%= @exception.message %>
<% if @exception.message.match? %r{#{ActiveStorage::Blob.table_name}|#{ActiveStorage::Attachment.table_name}} %>
To resolve this issue run: bin/rails active_storage:install
To resolve this issue run: rails active_storage:install
<% end %>
<%= render template: "rescues/_source" %>

10
activerecord/lib/active_record/migration.rb
View file

@ -130,9 +130,9 @@ module ActiveRecord
class PendingMigrationError < MigrationError#:nodoc:
def initialize(message = nil)
if !message && defined?(Rails.env)
super("Migrations are pending. To resolve this issue, run:\n\n bin/rails db:migrate RAILS_ENV=#{::Rails.env}")
super("Migrations are pending. To resolve this issue, run:\n\n rails db:migrate RAILS_ENV=#{::Rails.env}")
elsif !message
super("Migrations are pending. To resolve this issue, run:\n\n bin/rails db:migrate")
super("Migrations are pending. To resolve this issue, run:\n\n rails db:migrate")
else
super
end
@ -150,7 +150,7 @@ module ActiveRecord
class NoEnvironmentInSchemaError < MigrationError #:nodoc:
def initialize
msg = "Environment data not found in the schema. To resolve this issue, run: \n\n bin/rails db:environment:set"
msg = "Environment data not found in the schema. To resolve this issue, run: \n\n rails db:environment:set"
if defined?(Rails.env)
super("#{msg} RAILS_ENV=#{::Rails.env}")
else
@ -173,7 +173,7 @@ module ActiveRecord
msg = "You are attempting to modify a database that was last run in `#{ stored }` environment.\n".dup
msg << "You are running in `#{ current }` environment. "
msg << "If you are sure you want to continue, first set the environment using:\n\n"
msg << " bin/rails db:environment:set"
msg << " rails db:environment:set"
if defined?(Rails.env)
super("#{msg} RAILS_ENV=#{::Rails.env}\n\n")
else
@ -352,7 +352,7 @@ module ActiveRecord
# <tt>rails db:migrate</tt>. This will update the database by running all of the
# pending migrations, creating the <tt>schema_migrations</tt> table
# (see "About the schema_migrations table" section below) if missing. It will also
# invoke the db:schema:dump task, which will update your db/schema.rb file
# invoke the db:schema:dump command, which will update your db/schema.rb file
# to match the structure of your database.
#
# To roll the database back to a previous migration version, use

4
activerecord/lib/active_record/railtie.rb
View file

@ -141,8 +141,8 @@ Oops - You have a database configured, but it doesn't exist yet!
Here's how to get started:
1. Configure your database in config/database.yml.
2. Run `bin/rails db:create` to create the database.
3. Run `bin/rails db:setup` to load your database schema.
2. Run `rails db:create` to create the database.
3. Run `rails db:setup` to load your database schema.
end_warning
raise
end

2
activestorage/test/dummy/config/secrets.yml
View file

@ -25,7 +25,7 @@ test:
# Do not keep production secrets in the unencrypted secrets file.
# Instead, either read values from the environment.
# Or, use `bin/rails secrets:setup` to configure encrypted secrets
# Or, use `rails secrets:setup` to configure encrypted secrets
# and move the `production:` environment over there.
production:

2
activesupport/lib/active_support/key_generator.rb
View file

@ -59,7 +59,7 @@ module ActiveSupport
if secret.blank?
raise ArgumentError, "A secret is required to generate an integrity hash " \
"for cookie session data. Set a secret_key_base of at least " \
"#{SECRET_MIN_LENGTH} characters in via `bin/rails credentials:edit`."
"#{SECRET_MIN_LENGTH} characters by running `rails credentials:edit`."
end
if secret.length < SECRET_MIN_LENGTH

2
guides/source/action_controller_overview.md
View file

@ -395,7 +395,7 @@ You can also pass a `:domain` key and specify the domain name for the cookie:
Rails.application.config.session_store :cookie_store, key: '_your_app_session', domain: ".example.com"
```
Rails sets up (for the CookieStore) a secret key used for signing the session data in `config/credentials.yml.enc`. This can be changed with `bin/rails credentials:edit`.
Rails sets up (for the CookieStore) a secret key used for signing the session data in `config/credentials.yml.enc`. This can be changed with `rails credentials:edit`.
```ruby
# aws:

6
guides/source/action_mailer_basics.md
View file

@ -44,7 +44,7 @@ views.
#### Create the Mailer
```bash
$ bin/rails generate mailer UserMailer
$ rails generate mailer UserMailer
create app/mailers/user_mailer.rb
create app/mailers/application_mailer.rb
invoke erb
@ -173,8 +173,8 @@ Setting this up is painfully simple.
First, let's create a simple `User` scaffold:
```bash
$ bin/rails generate scaffold user name email login
$ bin/rails db:migrate
$ rails generate scaffold user name email login
$ rails db:migrate
```
Now that we have a user model to play with, we will just edit the

2
guides/source/action_view_overview.md
View file

@ -29,7 +29,7 @@ For each controller there is an associated directory in the `app/views` director
Let's take a look at what Rails does by default when creating a new resource using the scaffold generator:
```bash
$ bin/rails generate scaffold article
$ rails generate scaffold article
[...]
invoke scaffold_controller
create app/controllers/articles_controller.rb

4
guides/source/active_job_basics.md
View file

@ -50,7 +50,7 @@ Active Job provides a Rails generator to create jobs. The following will create
job in `app/jobs` (with an attached test case under `test/jobs`):
```bash
$ bin/rails generate job guests_cleanup
$ rails generate job guests_cleanup
invoke test_unit
create test/jobs/guests_cleanup_job_test.rb
create app/jobs/guests_cleanup_job.rb
@ -59,7 +59,7 @@ create app/jobs/guests_cleanup_job.rb
You can also create a job that will run on a specific queue:
```bash
$ bin/rails generate job guests_cleanup --queue urgent
$ rails generate job guests_cleanup --queue urgent
```
If you don't want to use a generator, you could create your own file inside of

58
guides/source/active_record_migrations.md
View file

@ -12,7 +12,7 @@ After reading this guide, you will know:
* The generators you can use to create them.
* The methods Active Record provides to manipulate your database.
* The bin/rails tasks that manipulate migrations and your schema.
* The rails commands that manipulate migrations and your schema.
* How migrations relate to `schema.rb`.
--------------------------------------------------------------------------------
@ -123,7 +123,7 @@ Of course, calculating timestamps is no fun, so Active Record provides a
generator to handle making it for you:
```bash
$ bin/rails generate migration AddPartNumberToProducts
$ rails generate migration AddPartNumberToProducts
```
This will create an empty but appropriately named migration:
@ -140,7 +140,7 @@ followed by a list of column names and types then a migration containing the
appropriate `add_column` and `remove_column` statements will be created.
```bash
$ bin/rails generate migration AddPartNumberToProducts part_number:string
$ rails generate migration AddPartNumberToProducts part_number:string
```
will generate
@ -156,7 +156,7 @@ end
If you'd like to add an index on the new column, you can do that as well:
```bash
$ bin/rails generate migration AddPartNumberToProducts part_number:string:index
$ rails generate migration AddPartNumberToProducts part_number:string:index
```
will generate
@ -174,7 +174,7 @@ end
Similarly, you can generate a migration to remove a column from the command line:
```bash
$ bin/rails generate migration RemovePartNumberFromProducts part_number:string
$ rails generate migration RemovePartNumberFromProducts part_number:string
```
generates
@ -190,7 +190,7 @@ end
You are not limited to one magically generated column. For example:
```bash
$ bin/rails generate migration AddDetailsToProducts part_number:string price:decimal
$ rails generate migration AddDetailsToProducts part_number:string price:decimal
```
generates
@ -209,7 +209,7 @@ followed by a list of column names and types then a migration creating the table
XXX with the columns listed will be generated. For example:
```bash
$ bin/rails generate migration CreateProducts name:string part_number:string
$ rails generate migration CreateProducts name:string part_number:string
```
generates
@ -233,7 +233,7 @@ Also, the generator accepts column type as `references` (also available as
`belongs_to`). For instance:
```bash
$ bin/rails generate migration AddUserRefToProducts user:references
$ rails generate migration AddUserRefToProducts user:references
```
generates
@ -252,7 +252,7 @@ For more `add_reference` options, visit the [API documentation](http://api.rubyo
There is also a generator which will produce join tables if `JoinTable` is part of the name:
```bash
$ bin/rails g migration CreateJoinTableCustomerProduct customer product
$ rails g migration CreateJoinTableCustomerProduct customer product
```
will produce the following migration:
@ -276,7 +276,7 @@ relevant table. If you tell Rails what columns you want, then statements for
adding these columns will also be created. For example, running:
```bash
$ bin/rails generate model Product name:string description:text
$ rails generate model Product name:string description:text
```
will create a migration that looks like this
@ -304,7 +304,7 @@ the command line. They are enclosed by curly braces and follow the field type:
For instance, running:
```bash
$ bin/rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplier:references{polymorphic}
$ rails generate migration AddDetailsToProducts 'price:decimal{5,2}' supplier:references{polymorphic}
```
will produce a migration that looks like this
@ -727,15 +727,15 @@ you will have to use `structure.sql` as dump method. See
Running Migrations
------------------
Rails provides a set of bin/rails tasks to run certain sets of migrations.
Rails provides a set of rails commands to run certain sets of migrations.
The very first migration related bin/rails task you will use will probably be
The very first migration related rails command you will use will probably be
`rails db:migrate`. In its most basic form it just runs the `change` or `up`
method for all the migrations that have not yet been run. If there are
no such migrations, it exits. It will run these migrations in order based
on the date of the migration.
Note that running the `db:migrate` task also invokes the `db:schema:dump` task, which
Note that running the `db:migrate` command also invokes the `db:schema:dump` command, which
will update your `db/schema.rb` file to match the structure of your database.
If you specify a target version, Active Record will run the required migrations
@ -744,7 +744,7 @@ is the numerical prefix on the migration's filename. For example, to migrate
to version 20080906120000 run:
```bash
$ bin/rails db:migrate VERSION=20080906120000
$ rails db:migrate VERSION=20080906120000
```
If version 20080906120000 is greater than the current version (i.e., it is
@ -761,7 +761,7 @@ mistake in it and wish to correct it. Rather than tracking down the version
number associated with the previous migration you can run:
```bash
$ bin/rails db:rollback
$ rails db:rollback
```
This will rollback the latest migration, either by reverting the `change`
@ -769,31 +769,31 @@ method or by running the `down` method. If you need to undo
several migrations you can provide a `STEP` parameter:
```bash
$ bin/rails db:rollback STEP=3
$ rails db:rollback STEP=3
```
will revert the last 3 migrations.
The `db:migrate:redo` task is a shortcut for doing a rollback and then migrating
back up again. As with the `db:rollback` task, you can use the `STEP` parameter
The `db:migrate:redo` command is a shortcut for doing a rollback and then migrating
back up again. As with the `db:rollback` command, you can use the `STEP` parameter
if you need to go more than one version back, for example:
```bash
$ bin/rails db:migrate:redo STEP=3
$ rails db:migrate:redo STEP=3
```
Neither of these bin/rails tasks do anything you could not do with `db:migrate`. They
Neither of these rails commands do anything you could not do with `db:migrate`. They
are simply more convenient, since you do not need to explicitly specify the
version to migrate to.
### Setup the Database
The `rails db:setup` task will create the database, load the schema, and initialize
The `rails db:setup` command will create the database, load the schema, and initialize
it with the seed data.
### Resetting the Database
The `rails db:reset` task will drop the database and set it up again. This is
The `rails db:reset` command will drop the database and set it up again. This is
functionally equivalent to `rails db:drop db:setup`.
NOTE: This is not the same as running all the migrations. It will only use the
@ -804,28 +804,28 @@ contents of the current `db/schema.rb` or `db/structure.sql` file. If a migratio
### Running Specific Migrations
If you need to run a specific migration up or down, the `db:migrate:up` and
`db:migrate:down` tasks will do that. Just specify the appropriate version and
`db:migrate:down` commands will do that. Just specify the appropriate version and
the corresponding migration will have its `change`, `up` or `down` method
invoked, for example:
```bash
$ bin/rails db:migrate:up VERSION=20080906120000
$ rails db:migrate:up VERSION=20080906120000
```
will run the 20080906120000 migration by running the `change` method (or the
`up` method). This task will
`up` method). This command will
first check whether the migration is already performed and will do nothing if
Active Record believes that it has already been run.
### Running Migrations in Different Environments
By default running `bin/rails db:migrate` will run in the `development` environment.
By default running `rails db:migrate` will run in the `development` environment.
To run migrations against another environment you can specify it using the
`RAILS_ENV` environment variable while running the command. For example to run
migrations against the `test` environment you could run:
```bash
$ bin/rails db:migrate RAILS_ENV=test
$ rails db:migrate RAILS_ENV=test
```
### Changing the Output of Running Migrations
@ -896,7 +896,7 @@ Occasionally you will make a mistake when writing a migration. If you have
already run the migration, then you cannot just edit the migration and run the
migration again: Rails thinks it has already run the migration and so will do
nothing when you run `rails db:migrate`. You must rollback the migration (for
example with `bin/rails db:rollback`), edit your migration, and then run
example with `rails db:rollback`), edit your migration, and then run
`rails db:migrate` to run the corrected version.
In general, editing existing migrations is not a good idea. You will be

2
guides/source/active_record_postgresql.md
View file

@ -276,7 +276,7 @@ end
NOTE: ENUM values can't be dropped currently. You can read why [here](https://www.postgresql.org/message-id/29F36C7C98AB09499B1A209D48EAA615B7653DBC8A@mail2a.alliedtesting.com).
Hint: to show all the values of the all enums you have, you should call this query in `bin/rails db` or `psql` console:
Hint: to show all the values of the all enums you have, you should call this query in `rails db` or `psql` console:
```sql
SELECT n.nspname AS enum_schema,

2
guides/source/active_record_validations.md
View file

@ -87,7 +87,7 @@ end
We can see how it works by looking at some `rails console` output:
```ruby
$ bin/rails console
$ rails console
>> p = Person.new(name: "John Doe")
=> #<Person id: nil, name: "John Doe", created_at: nil, updated_at: nil>
>> p.new_record?

2
guides/source/api_app.md
View file

@ -391,7 +391,7 @@ Other plugins may add additional modules. You can get a list of all modules
included into `ActionController::API` in the rails console:
```bash
$ bin/rails c
$ rails c
>> ActionController::API.ancestors - ActionController::Metal.ancestors
=> [ActionController::API,
ActiveRecord::Railties::ControllerRuntime,

12
guides/source/asset_pipeline.md
View file

@ -673,20 +673,20 @@ content changes.
### Precompiling Assets
Rails comes bundled with a task to compile the asset manifests and other
Rails comes bundled with a command to compile the asset manifests and other
files in the pipeline.
Compiled assets are written to the location specified in `config.assets.prefix`.
By default, this is the `/assets` directory.
You can call this task on the server during deployment to create compiled
You can call this command on the server during deployment to create compiled
versions of your assets directly on the server. See the next section for
information on compiling locally.
The task is:
The command is:
```bash
$ RAILS_ENV=production bin/rails assets:precompile
$ RAILS_ENV=production rails assets:precompile
```
Capistrano (v2.15.1 and above) includes a recipe to handle this in deployment.
@ -698,7 +698,7 @@ load 'deploy/assets'
This links the folder specified in `config.assets.prefix` to `shared/assets`.
If you already use this shared folder you'll need to write your own deployment
task.
command.
It is important that this folder is shared between deployments so that remotely
cached pages referencing the old compiled assets still work for the life of
@ -728,7 +728,7 @@ Rails.application.config.assets.precompile += %w( admin.js admin.css )
NOTE. Always specify an expected compiled filename that ends with `.js` or `.css`,
even if you want to add Sass or CoffeeScript files to the precompile array.
The task also generates a `.sprockets-manifest-randomhex.json` (where `randomhex` is
The command also generates a `.sprockets-manifest-randomhex.json` (where `randomhex` is
a 16-byte random hex string) that contains a list with all your assets and their respective
fingerprints. This is used by the Rails helper methods to avoid handing the
mapping requests back to Sprockets. A typical manifest file looks like:

26
guides/source/autoloading_and_reloading_constants.md
View file

@ -410,7 +410,7 @@ Rails is always able to autoload provided its environment is in place. For
example the `runner` command autoloads:
```
$ bin/rails runner 'p User.column_names'
$ rails runner 'p User.column_names'
["id", "email", "created_at", "updated_at"]
```
@ -470,10 +470,10 @@ default it contains:
`eager_load_paths` is initially the `app` paths above
How files are autoloaded depends on `eager_load` and `cache_classes` config settings which typically vary in development, production, and test modes:
* In **development**, you want quicker startup with incremental loading of application code. So `eager_load` should be set to `false`, and Rails will autoload files as needed (see [Autoloading Algorithms](#autoloading-algorithms) below) -- and then reload them when they change (see [Constant Reloading](#constant-reloading) below).
* In **production**, however you want consistency and thread-safety and can live with a longer boot time. So `eager_load` is set to `true`, and then during boot (before the app is ready to receive requests) Rails loads all files in the `eager_load_paths` and then turns off auto loading (NB: autoloading may be needed during eager loading). Not autoloading after boot is a `good thing`, as autoloading can cause the app to be have thread-safety problems.
* In **test**, for speed of execution (of individual tests) `eager_load` is `false`, so Rails follows development behaviour.
* In **production**, however, you want consistency and thread-safety and can live with a longer boot time. So `eager_load` is set to `true`, and then during boot (before the app is ready to receive requests) Rails loads all files in the `eager_load_paths` and then turns off auto loading (NB: autoloading may be needed during eager loading). Not autoloading after boot is a `good thing`, as autoloading can cause the app to be have thread-safety problems.
* In **test**, for speed of execution (of individual tests) `eager_load` is `false`, so Rails follows development behaviour.
What is described above are the defaults with a newly generated Rails app. There are multiple ways this can be configured differently (see [Configuring Rails Applications](configuring.html#rails-general-configuration).
). But using `autoload_paths` on its own in the past (before Rails 5) developers might configure `autoload_paths` to add in extra locations (e.g. `lib` which used to be an autoload path list years ago, but no longer is). However this is now discouraged for most purposes, as it is likely to lead to production-only errors. It is possible to add new locations to both `config.eager_load_paths` and `config.autoload_paths` but use at your own risk.
@ -486,7 +486,7 @@ The value of `autoload_paths` can be inspected. In a just-generated application
it is (edited):
```
$ bin/rails r 'puts ActiveSupport::Dependencies.autoload_paths'
$ rails r 'puts ActiveSupport::Dependencies.autoload_paths'
.../app/assets
.../app/channels
.../app/controllers
@ -1220,7 +1220,7 @@ been loaded but `app/models/hotel/image.rb` hasn't, Ruby does not find `Image`
in `Hotel`, but it does in `Object`:
```
$ bin/rails r 'Image; p Hotel::Image' 2>/dev/null
$ rails r 'Image; p Hotel::Image' 2>/dev/null
Image # NOT Hotel::Image!
```
@ -1338,15 +1338,15 @@ end
```
### Autoloading in the Test Environment
When configuring the `test` environment for autoloading you might consider multiple factors.
For example it might be worth running your tests with an identical setup to production (`config.eager_load = true`, `config.cache_classes = true`) in order to catch any problems before they hit production (this is compensation for the lack of dev-prod parity). However this will slow down the boot time for individual tests on a dev machine (and is not immediately compatible with spring see below). So one possibility is to do this on a
[CI](https://en.wikipedia.org/wiki/Continuous_integration) machine only (which should run without spring).
When configuring the `test` environment for autoloading you might consider multiple factors.
On a development machine you can then have your tests running with whatever is fastest (ideally `config.eager_load = false`).
For example it might be worth running your tests with an identical setup to production (`config.eager_load = true`, `config.cache_classes = true`) in order to catch any problems before they hit production (this is compensation for the lack of dev-prod parity). However this will slow down the boot time for individual tests on a dev machine (and is not immediately compatible with spring see below). So one possibility is to do this on a
[CI](https://en.wikipedia.org/wiki/Continuous_integration) machine only (which should run without spring).
With the [Spring](https://github.com/rails/spring) pre-loader (included with new Rails apps), you ideally keep `config.eager_load = false` as per development. Sometimes you may end up with a hybrid configuration (`config.eager_load = true`, `config.cache_classes = true` AND `config.enable_dependency_loading = true`), see [spring issue](https://github.com/rails/spring/issues/519#issuecomment-348324369). However it might be simpler to keep the same configuration as development, and work out whatever it is that is causing autoloading to fail (perhaps by the results of your CI test results).
On a development machine you can then have your tests running with whatever is fastest (ideally `config.eager_load = false`).
With the [Spring](https://github.com/rails/spring) pre-loader (included with new Rails apps), you ideally keep `config.eager_load = false` as per development. Sometimes you may end up with a hybrid configuration (`config.eager_load = true`, `config.cache_classes = true` AND `config.enable_dependency_loading = true`), see [spring issue](https://github.com/rails/spring/issues/519#issuecomment-348324369). However it might be simpler to keep the same configuration as development, and work out whatever it is that is causing autoloading to fail (perhaps by the results of your CI test results).
Occasionally you may need to explicitly eager_load by using `Rails
.application.eager_load!` in the setup of your tests -- this might occur if your [tests involve multithreading](https://stackoverflow.com/questions/25796409/in-rails-how-can-i-eager-load-all-code-before-a-specific-rspec-test).
.application.eager_load!` in the setup of your tests -- this might occur if your [tests involve multithreading](https://stackoverflow.com/questions/25796409/in-rails-how-can-i-eager-load-all-code-before-a-specific-rspec-test).

6
guides/source/caching_with_rails.md
View file

@ -670,13 +670,13 @@ Caching in Development
----------------------
It's common to want to test the caching strategy of your application
in development mode. Rails provides the rake task `dev:cache` to
in development mode. Rails provides the rails command `dev:cache` to
easily toggle caching on/off.
```bash
$ bin/rails dev:cache
$ rails dev:cache
Development mode is now being cached.
$ bin/rails dev:cache
$ rails dev:cache
Development mode is no longer being cached.
```

169
guides/source/command_line.md
View file

@ -21,12 +21,51 @@ There are a few commands that are absolutely critical to your everyday usage of
* `rails console`
* `rails server`
* `bin/rails`
* `rails test`
* `rails generate`
* `rails db:migrate`
* `rails db:create`
* `rails routes`
* `rails dbconsole`
* `rails new app_name`
All commands can run with `-h` or `--help` to list more information.
You can get a list of rails commands available to you, which will often depend on your current directory, by typing `rails --help`. Each command has a description, and should help you find the thing you need.
```bash
$ rails --help
Usage: rails COMMAND [ARGS]
The most common rails commands are:
generate Generate new code (short-cut alias: "g")
console Start the Rails console (short-cut alias: "c")
server Start the Rails server (short-cut alias: "s")
...
All commands can be run with -h (or --help) for more information.
In addition to those commands, there are:
about List versions of all Rails ...
assets:clean[keep] Remove old compiled assets
assets:clobber Remove compiled assets
assets:environment Load asset compile environment
assets:precompile Compile all the assets ...
...
db:fixtures:load Loads fixtures into the ...
db:migrate Migrate the database ...
db:migrate:status Display status of migrations
db:rollback Rolls the schema back to ...
db:schema:cache:clear Clears a db/schema_cache.yml file
db:schema:cache:dump Creates a db/schema_cache.yml file
db:schema:dump Creates a db/schema.rb file ...
db:schema:load Loads a schema.rb file ...
db:seed Loads the seed data ...
db:structure:dump Dumps the database structure ...
db:structure:load Recreates the databases ...
db:version Retrieves the current schema ...
...
restart Restart app by touching ...
tmp:create Creates tmp directories ...
```
Let's create a simple Rails application to step through each of these commands in context.
@ -61,7 +100,7 @@ With no further work, `rails server` will run our new shiny Rails app:
```bash
$ cd commandsapp
$ bin/rails server
$ rails server
=> Booting Puma
=> Rails 5.1.0 application starting in development on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
@ -80,7 +119,7 @@ INFO: You can also use the alias "s" to start the server: `rails s`.
The server can be run on a different port using the `-p` option. The default development environment can be changed using `-e`.
```bash
$ bin/rails server -e production -p 4000
$ rails server -e production -p 4000
```
The `-b` option binds Rails to the specified IP, by default it is localhost. You can run a server as a daemon by passing a `-d` option.
@ -92,7 +131,7 @@ The `rails generate` command uses templates to create a whole lot of things. Run
INFO: You can also use the alias "g" to invoke the generator command: `rails g`.
```bash
$ bin/rails generate
$ rails generate
Usage: rails generate GENERATOR [args] [options]
...
@ -118,7 +157,7 @@ Let's make our own controller with the controller generator. But what command sh
INFO: All Rails console utilities have help text. As with most *nix utilities, you can try adding `--help` or `-h` to the end, for example `rails server --help`.
```bash
$ bin/rails generate controller
$ rails generate controller
Usage: rails generate controller NAME [action action] [options]
...
@ -144,7 +183,7 @@ Example:
The controller generator is expecting parameters in the form of `generate controller ControllerName action1 action2`. Let's make a `Greetings` controller with an action of **hello**, which will say something nice to us.
```bash
$ bin/rails generate controller Greetings hello
$ rails generate controller Greetings hello
create app/controllers/greetings_controller.rb
route get "greetings/hello"
invoke erb
@ -183,7 +222,7 @@ Then the view, to display our message (in `app/views/greetings/hello.html.erb`):
Fire up your server using `rails server`.
```bash
$ bin/rails server
$ rails server
=> Booting Puma...
```
@ -194,7 +233,7 @@ INFO: With a normal, plain-old Rails application, your URLs will generally follo
Rails comes with a generator for data models too.
```bash
$ bin/rails generate model
$ rails generate model
Usage:
rails generate model NAME [field[:type][:index] field[:type][:index]] [options]
@ -217,7 +256,7 @@ But instead of generating a model directly (which we'll be doing later), let's s
We will set up a simple resource called "HighScore" that will keep track of our highest score on video games we play.
```bash
$ bin/rails generate scaffold HighScore game:string score:integer
$ rails generate scaffold HighScore game:string score:integer
invoke active_record
create db/migrate/20130717151933_create_high_scores.rb
create app/models/high_score.rb
@ -255,10 +294,10 @@ $ bin/rails generate scaffold HighScore game:string score:integer
The generator checks that there exist the directories for models, controllers, helpers, layouts, functional and unit tests, stylesheets, creates the views, controller, model and database migration for HighScore (creating the `high_scores` table and fields), takes care of the route for the **resource**, and new tests for everything.
The migration requires that we **migrate**, that is, run some Ruby code (living in that `20130717151933_create_high_scores.rb`) to modify the schema of our database. Which database? The SQLite3 database that Rails will create for you when we run the `bin/rails db:migrate` command. We'll talk more about bin/rails in-depth in a little while.
The migration requires that we **migrate**, that is, run some Ruby code (living in that `20130717151933_create_high_scores.rb`) to modify the schema of our database. Which database? The SQLite3 database that Rails will create for you when we run the `rails db:migrate` command. We'll talk more about that command below.
```bash
$ bin/rails db:migrate
$ rails db:migrate
== CreateHighScores: migrating ===============================================
-- create_table(:high_scores)
-> 0.0017s
@ -276,7 +315,7 @@ look at unit testing.
Let's see the interface Rails created for us.
```bash
$ bin/rails server
$ rails server
```
Go to your browser and open [http://localhost:3000/high_scores](http://localhost:3000/high_scores), now we can create new high scores (55,160 on Space Invaders!)
@ -290,13 +329,13 @@ INFO: You can also use the alias "c" to invoke the console: `rails c`.
You can specify the environment in which the `console` command should operate.
```bash
$ bin/rails console -e staging
$ rails console -e staging
```
If you wish to test out some code without changing any data, you can do that by invoking `rails console --sandbox`.
```bash
$ bin/rails console --sandbox
$ rails console --sandbox
Loading development environment in sandbox (Rails 5.1.0)
Any modifications you make will be rolled back on exit
irb(main):001:0>
@ -338,7 +377,7 @@ INFO: You can also use the alias "db" to invoke the dbconsole: `rails db`.
`runner` runs Ruby code in the context of Rails non-interactively. For instance:
```bash
$ bin/rails runner "Model.long_running_method"
$ rails runner "Model.long_running_method"
```
INFO: You can also use the alias "r" to invoke the runner: `rails r`.
@ -346,13 +385,13 @@ INFO: You can also use the alias "r" to invoke the runner: `rails r`.
You can specify the environment in which the `runner` command should operate using the `-e` switch.
```bash
$ bin/rails runner -e staging "Model.long_running_method"
$ rails runner -e staging "Model.long_running_method"
```
You can even execute ruby code written in a file with runner.
```bash
$ bin/rails runner lib/code_to_be_run.rb
$ rails runner lib/code_to_be_run.rb
```
### `rails destroy`
@ -362,7 +401,7 @@ Think of `destroy` as the opposite of `generate`. It'll figure out what generate
INFO: You can also use the alias "d" to invoke the destroy command: `rails d`.
```bash
$ bin/rails generate model Oops
$ rails generate model Oops
invoke active_record
create db/migrate/20120528062523_create_oops.rb
create app/models/oops.rb
@ -371,7 +410,7 @@ $ bin/rails generate model Oops
create test/fixtures/oops.yml
```
```bash
$ bin/rails destroy model Oops
$ rails destroy model Oops
invoke active_record
remove db/migrate/20120528062523_create_oops.rb
remove app/models/oops.rb
@ -380,56 +419,12 @@ $ bin/rails destroy model Oops
remove test/fixtures/oops.yml
```
bin/rails
---------
### `rails about`
Since Rails 5.0+ has rake commands built into the rails executable, `bin/rails` is the new default for running commands.
You can get a list of bin/rails tasks available to you, which will often depend on your current directory, by typing `bin/rails --help`. Each task has a description, and should help you find the thing you need.
`rails about` gives information about version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version. It is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.
```bash
$ bin/rails --help
Usage: rails COMMAND [ARGS]
The most common rails commands are:
generate Generate new code (short-cut alias: "g")
console Start the Rails console (short-cut alias: "c")
server Start the Rails server (short-cut alias: "s")
...
All commands can be run with -h (or --help) for more information.
In addition to those commands, there are:
about List versions of all Rails ...
assets:clean[keep] Remove old compiled assets
assets:clobber Remove compiled assets
assets:environment Load asset compile environment
assets:precompile Compile all the assets ...
...
db:fixtures:load Loads fixtures into the ...
db:migrate Migrate the database ...
db:migrate:status Display status of migrations
db:rollback Rolls the schema back to ...
db:schema:cache:clear Clears a db/schema_cache.yml file
db:schema:cache:dump Creates a db/schema_cache.yml file
db:schema:dump Creates a db/schema.rb file ...
db:schema:load Loads a schema.rb file ...
db:seed Loads the seed data ...
db:structure:dump Dumps the database structure ...
db:structure:load Recreates the databases ...
db:version Retrieves the current schema ...
...
restart Restart app by touching ...
tmp:create Creates tmp directories ...
```
INFO: You can also use `bin/rails -T` to get the list of tasks.
### `about`
`bin/rails about` gives information about version numbers for Ruby, RubyGems, Rails, the Rails subcomponents, your application's folder, the current Rails environment name, your app's database adapter, and schema version. It is useful when you need to ask for help, check if a security patch might affect you, or when you need some stats for an existing Rails installation.
```bash
$ bin/rails about
$ rails about
About your application's environment
Rails version 6.0.0
Ruby version 2.5.0 (x86_64-linux)
@ -443,26 +438,26 @@ Database adapter sqlite3
Database schema version 20180205173523
```
### `assets`
### `rails assets:`
You can precompile the assets in `app/assets` using `bin/rails assets:precompile`, and remove older compiled assets using `bin/rails assets:clean`. The `assets:clean` task allows for rolling deploys that may still be linking to an old asset while the new assets are being built.
You can precompile the assets in `app/assets` using `rails assets:precompile`, and remove older compiled assets using `rails assets:clean`. The `assets:clean` command allows for rolling deploys that may still be linking to an old asset while the new assets are being built.
If you want to clear `public/assets` completely, you can use `bin/rails assets:clobber`.
If you want to clear `public/assets` completely, you can use `rails assets:clobber`.
### `db`
### `rails db:`
The most common tasks of the `db:` bin/rails namespace are `migrate` and `create`, and it will pay off to try out all of the migration bin/rails tasks (`up`, `down`, `redo`, `reset`). `bin/rails db:version` is useful when troubleshooting, telling you the current version of the database.
The most common commands of the `db:` rails namespace are `migrate` and `create`, and it will pay off to try out all of the migration rails commands (`up`, `down`, `redo`, `reset`). `rails db:version` is useful when troubleshooting, telling you the current version of the database.
More information about migrations can be found in the [Migrations](active_record_migrations.html) guide.
### `notes`
### `rails notes`
`bin/rails notes` searches through your code for comments beginning with a specific keyword. You can refer to `bin/rails notes --help` for information about usage.
`rails notes` searches through your code for comments beginning with a specific keyword. You can refer to `rails notes --help` for information about usage.
By default, it will search in `app`, `config`, `db`, `lib`, and `test` directories for FIXME, OPTIMIZE, and TODO annotations in files with extension `.builder`, `.rb`, `.rake`, `.yml`, `.yaml`, `.ruby`, `.css`, `.js`, and `.erb`.
```bash
$ bin/rails notes
$ rails notes
app/controllers/admin/users_controller.rb:
* [ 20] [TODO] any other way to do this?
* [132] [FIXME] high priority for next deploy
@ -478,7 +473,7 @@ You can pass specific annotations by using the `--annotations` argument. By defa
Note that annotations are case sensitive.
```bash
$ bin/rails notes --annotations FIXME RELEASE
$ rails notes --annotations FIXME RELEASE
app/controllers/admin/users_controller.rb:
* [101] [RELEASE] We need to look at this before next release
* [132] [FIXME] high priority for next deploy
@ -496,7 +491,7 @@ config.annotations.register_directories("spec", "vendor")
```
```bash
$ bin/rails notes
$ rails notes
app/controllers/admin/users_controller.rb:
* [ 20] [TODO] any other way to do this?
* [132] [FIXME] high priority for next deploy
@ -521,7 +516,7 @@ config.annotations.register_extensions("scss", "sass") { |annotation| /\/\/\s*(#
```
```bash
$ bin/rails notes
$ rails notes
app/controllers/admin/users_controller.rb:
* [ 20] [TODO] any other way to do this?
* [132] [FIXME] high priority for next deploy
@ -543,21 +538,21 @@ vendor/tools.rb:
* [ 56] [TODO] Get rid of this dependency
```
### `routes`
### `rails routes`
`rails routes` will list all of your defined routes, which is useful for tracking down routing problems in your app, or giving you a good overview of the URLs in an app you're trying to get familiar with.
### `test`
### `rails test`
INFO: A good description of unit testing in Rails is given in [A Guide to Testing Rails Applications](testing.html)
Rails comes with a test suite called Minitest. Rails owes its stability to the use of tests. The tasks available in the `test:` namespace helps in running the different tests you will hopefully write.
Rails comes with a test suite called Minitest. Rails owes its stability to the use of tests. The commands available in the `test:` namespace helps in running the different tests you will hopefully write.
### `tmp`
### `rails tmp:`
The `Rails.root/tmp` directory is, like the *nix /tmp directory, the holding place for temporary files like process id files and cached actions.
The `tmp:` namespaced tasks will help you clear and create the `Rails.root/tmp` directory:
The `tmp:` namespaced commands will help you clear and create the `Rails.root/tmp` directory:
* `rails tmp:cache:clear` clears `tmp/cache`.
* `rails tmp:sockets:clear` clears `tmp/sockets`.
@ -575,7 +570,7 @@ The `tmp:` namespaced tasks will help you clear and create the `Rails.root/tmp`
Custom rake tasks have a `.rake` extension and are placed in
`Rails.root/lib/tasks`. You can create these custom rake tasks with the
`bin/rails generate task` command.
`rails generate task` command.
```ruby
desc "I am short, but comprehensive description for my cool task"
@ -607,9 +602,9 @@ end
Invocation of the tasks will look like:
```bash
$ bin/rails task_name
$ bin/rails "task_name[value 1]" # entire argument string should be quoted
$ bin/rails db:nothing
$ rails task_name
$ rails "task_name[value 1]" # entire argument string should be quoted
$ rails db:nothing
```
NOTE: If your need to interact with your application models, perform database queries, and so on, your task should depend on the `environment` task, which will load your application code.

8
guides/source/configuring.md
View file

@ -374,7 +374,7 @@ All these configuration options are delegated to the `I18n` library.
Defaults to `false`.
* `config.active_record.use_schema_cache_dump` enables users to get schema cache information
from `db/schema_cache.yml` (generated by `bin/rails db:schema:cache:dump`), instead of
from `db/schema_cache.yml` (generated by `rails db:schema:cache:dump`), instead of
having to send a query to the database to get this information.
Defaults to `true`.
@ -907,7 +907,7 @@ development:
$ echo $DATABASE_URL
postgresql://localhost/my_database
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
$ rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"postgresql", "host"=>"localhost", "database"=>"my_database"}}
```
@ -924,7 +924,7 @@ development:
$ echo $DATABASE_URL
postgresql://localhost/my_database
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
$ rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"postgresql", "host"=>"localhost", "database"=>"my_database", "pool"=>5}}
```
@ -940,7 +940,7 @@ development:
$ echo $DATABASE_URL
postgresql://localhost/my_database
$ bin/rails runner 'puts ActiveRecord::Base.configurations'
$ rails runner 'puts ActiveRecord::Base.configurations'
{"development"=>{"adapter"=>"sqlite3", "database"=>"NOT_my_database"}}
```

32
guides/source/engines.md
View file

@ -202,7 +202,7 @@ within the `Engine` class definition. Without it, classes generated in an engine
**may** conflict with an application.
What this isolation of the namespace means is that a model generated by a call
to `bin/rails g model`, such as `bin/rails g model article`, won't be called `Article`, but
to `rails g model`, such as `rails g model article`, won't be called `Article`, but
instead be namespaced and called `Blorgh::Article`. In addition, the table for the
model is namespaced, becoming `blorgh_articles`, rather than simply `articles`.
Similar to the model namespacing, a controller called `ArticlesController` becomes
@ -322,7 +322,7 @@ The first thing to generate for a blog engine is the `Article` model and related
controller. To quickly generate this, you can use the Rails scaffold generator.
```bash
$ bin/rails generate scaffold article title:string text:text
$ rails generate scaffold article title:string text:text
```
This command will output this information:
@ -430,7 +430,7 @@ Finally, the assets for this resource are generated in two files:
`app/assets/stylesheets/blorgh/articles.css`. You'll see how to use these a little
later.
You can see what the engine has so far by running `bin/rails db:migrate` at the root
You can see what the engine has so far by running `rails db:migrate` at the root
of our engine to run the migration generated by the scaffold generator, and then
running `rails server` in `test/dummy`. When you open
`http://localhost:3000/blorgh/articles` you will see the default scaffold that has
@ -472,7 +472,7 @@ From the application root, run the model generator. Tell it to generate a
and `text` text column.
```bash
$ bin/rails generate model Comment article_id:integer text:text
$ rails generate model Comment article_id:integer text:text
```
This will output the following:
@ -492,7 +492,7 @@ called `Blorgh::Comment`. Now run the migration to create our blorgh_comments
table:
```bash
$ bin/rails db:migrate
$ rails db:migrate
```
To show the comments on an article, edit `app/views/blorgh/articles/show.html.erb` and
@ -566,7 +566,7 @@ The route now exists, but the controller that this route goes to does not. To
create it, run this command from the application root:
```bash
$ bin/rails g controller comments
$ rails g controller comments
```
This will generate the following things:
@ -701,14 +701,14 @@ engine's models can query them correctly. To copy these migrations into the
application run the following command from the application's root:
```bash
$ bin/rails blorgh:install:migrations
$ rails blorgh:install:migrations
```
If you have multiple engines that need migrations copied over, use
`railties:install:migrations` instead:
```bash
$ bin/rails railties:install:migrations
$ rails railties:install:migrations
```
This command, when run for the first time, will copy over all the migrations
@ -726,7 +726,7 @@ timestamp (`[timestamp_2]`) will be the current time plus a second. The reason
for this is so that the migrations for the engine are run after any existing
migrations in the application.
To run these migrations within the context of the application, simply run `bin/rails
To run these migrations within the context of the application, simply run `rails
db:migrate`. When accessing the engine through `http://localhost:3000/blog`, the
articles will be empty. This is because the table created inside the application is
different from the one created within the engine. Go ahead, play around with the
@ -737,14 +737,14 @@ If you would like to run migrations only from one engine, you can do it by
specifying `SCOPE`:
```bash
bin/rails db:migrate SCOPE=blorgh
rails db:migrate SCOPE=blorgh
```
This may be useful if you want to revert engine's migrations before removing it.
To revert all migrations from blorgh engine you can run code such as:
```bash
bin/rails db:migrate SCOPE=blorgh VERSION=0
rails db:migrate SCOPE=blorgh VERSION=0
```
### Using a Class Provided by the Application
@ -771,7 +771,7 @@ application:
rails g model user name:string
```
The `bin/rails db:migrate` command needs to be run here to ensure that our
The `rails db:migrate` command needs to be run here to ensure that our
application has the `users` table for future use.
Also, to keep it simple, the articles form will have a new text field called
@ -831,7 +831,7 @@ of associating the records in the `blorgh_articles` table with the records in th
To generate this new column, run this command within the engine:
```bash
$ bin/rails g migration add_author_id_to_blorgh_articles author_id:integer
$ rails g migration add_author_id_to_blorgh_articles author_id:integer
```
NOTE: Due to the migration's name and the column specification after it, Rails
@ -843,7 +843,7 @@ This migration will need to be run on the application. To do that, it must first
be copied using this command:
```bash
$ bin/rails blorgh:install:migrations
$ rails blorgh:install:migrations
```
Notice that only _one_ migration was copied over here. This is because the first
@ -858,7 +858,7 @@ Copied migration [timestamp]_add_author_id_to_blorgh_articles.blorgh.rb from blo
Run the migration using:
```bash
$ bin/rails db:migrate
$ rails db:migrate
```
Now with all the pieces in place, an action will take place that will associate
@ -1365,7 +1365,7 @@ need to require `admin.css` or `admin.js`. Only the gem's admin layout needs
these assets. It doesn't make sense for the host app to include
`"blorgh/admin.css"` in its stylesheets. In this situation, you should
explicitly define these assets for precompilation. This tells Sprockets to add
your engine assets when `bin/rails assets:precompile` is triggered.
your engine assets when `rails assets:precompile` is triggered.
You can define assets for precompilation in `engine.rb`:

24
guides/source/generators.md
View file

@ -26,13 +26,13 @@ When you create an application using the `rails` command, you are in fact using
```bash
$ rails new myapp
$ cd myapp
$ bin/rails generate
$ rails generate
```
You will get a list of all generators that comes with Rails. If you need a detailed description of the helper generator, for example, you can simply do:
```bash
$ bin/rails generate helper --help
$ rails generate helper --help
```
Creating Your First Generator
@ -57,13 +57,13 @@ Our new generator is quite simple: it inherits from `Rails::Generators::Base` an
To invoke our new generator, we just need to do:
```bash
$ bin/rails generate initializer
$ rails generate initializer
```
Before we go on, let's see our brand new generator description:
```bash
$ bin/rails generate initializer --help
$ rails generate initializer --help
```
Rails is usually able to generate good descriptions if a generator is namespaced, as `ActiveRecord::Generators::ModelGenerator`, but not in this particular case. We can solve this problem in two ways. The first one is calling `desc` inside our generator:
@ -85,7 +85,7 @@ Creating Generators with Generators
Generators themselves have a generator:
```bash
$ bin/rails generate generator initializer
$ rails generate generator initializer
create lib/generators/initializer
create lib/generators/initializer/initializer_generator.rb
create lib/generators/initializer/USAGE
@ -107,7 +107,7 @@ First, notice that we are inheriting from `Rails::Generators::NamedBase` instead
We can see that by invoking the description of this new generator (don't forget to delete the old generator file):
```bash
$ bin/rails generate initializer --help
$ rails generate initializer --help
Usage:
rails generate initializer NAME [options]
```
@ -135,7 +135,7 @@ end
And let's execute our generator:
```bash
$ bin/rails generate initializer core_extensions
$ rails generate initializer core_extensions
```
We can see that now an initializer named core_extensions was created at `config/initializers/core_extensions.rb` with the contents of our template. That means that `copy_file` copied a file in our source root to the destination path we gave. The method `file_name` is automatically created when we inherit from `Rails::Generators::NamedBase`.
@ -174,7 +174,7 @@ end
Before we customize our workflow, let's first see what our scaffold looks like:
```bash
$ bin/rails generate scaffold User name:string
$ rails generate scaffold User name:string
invoke active_record
create db/migrate/20130924151154_create_users.rb
create app/models/user.rb
@ -238,7 +238,7 @@ If we generate another resource with the scaffold generator, we can see that sty
To demonstrate this, we are going to create a new helper generator that simply adds some instance variable readers. First, we create a generator within the rails namespace, as this is where rails searches for generators used as hooks:
```bash
$ bin/rails generate generator rails/my_helper
$ rails generate generator rails/my_helper
create lib/generators/rails/my_helper
create lib/generators/rails/my_helper/my_helper_generator.rb
create lib/generators/rails/my_helper/USAGE
@ -267,7 +267,7 @@ end
We can try out our new generator by creating a helper for products:
```bash
$ bin/rails generate my_helper products
$ rails generate my_helper products
create app/helpers/products_helper.rb
```
@ -295,7 +295,7 @@ end
and see it in action when invoking the generator:
```bash
$ bin/rails generate scaffold Article body:text
$ rails generate scaffold Article body:text
[...]
invoke my_helper
create app/helpers/articles_helper.rb
@ -397,7 +397,7 @@ end
Now, if you create a Comment scaffold, you will see that the shoulda generators are being invoked, and at the end, they are just falling back to TestUnit generators:
```bash
$ bin/rails generate scaffold Comment body:text
$ rails generate scaffold Comment body:text
invoke active_record
create db/migrate/20130924143118_create_comments.rb
create app/models/comment.rb

44
guides/source/getting_started.md
View file

@ -93,8 +93,8 @@ ruby 2.5.0
Rails requires Ruby version 2.4.1 or later. If the version number returned is
less than that number, you'll need to install a fresh copy of Ruby.
TIP: To quickly install Ruby and Ruby on Rails on your system in Windows, you can use
[Rails Installer](http://railsinstaller.org). For more installation methods for most
TIP: To quickly install Ruby and Ruby on Rails on your system in Windows, you can use
[Rails Installer](http://railsinstaller.org). For more installation methods for most
Operating Systems take a look at [ruby-lang.org](https://www.ruby-lang.org/en/documentation/installation/).
If you are working on Windows, you should also install the
@ -199,7 +199,7 @@ start a web server on your development machine. You can do this by running the
following in the `blog` directory:
```bash
$ bin/rails server
$ rails server
```
TIP: If you are using Windows, you have to pass the scripts under the `bin`
@ -255,7 +255,7 @@ tell it you want a controller called "Welcome" with an action called "index",
just like this:
```bash
$ bin/rails generate controller Welcome index
$ rails generate controller Welcome index
```
Rails will create several files and a route for you.
@ -328,9 +328,9 @@ end
application to the welcome controller's index action and `get 'welcome/index'`
tells Rails to map requests to <http://localhost:3000/welcome/index> to the
welcome controller's index action. This was created earlier when you ran the
controller generator (`bin/rails generate controller Welcome index`).
controller generator (`rails generate controller Welcome index`).
Launch the web server again if you stopped it to generate the controller (`bin/rails
Launch the web server again if you stopped it to generate the controller (`rails
server`) and navigate to <http://localhost:3000> in your browser. You'll see the
"Hello, Rails!" message you put into `app/views/welcome/index.html.erb`,
indicating that this new route is indeed going to `WelcomeController`'s `index`
@ -364,13 +364,13 @@ Rails.application.routes.draw do
end
```
If you run `bin/rails routes`, you'll see that it has defined routes for all the
If you run `rails routes`, you'll see that it has defined routes for all the
standard RESTful actions. The meaning of the prefix column (and other columns)
will be seen later, but for now notice that Rails has inferred the
singular form `article` and makes meaningful use of the distinction.
```bash
$ bin/rails routes
$ rails routes
Prefix Verb URI Pattern Controller#Action
welcome_index GET /welcome/index(.:format) welcome#index
articles GET /articles(.:format) articles#index
@ -409,7 +409,7 @@ a controller called `ArticlesController`. You can do this by running this
command:
```bash
$ bin/rails generate controller Articles
$ rails generate controller Articles
```
If you open up the newly generated `app/controllers/articles_controller.rb`
@ -561,10 +561,10 @@ this:
In this example, the `articles_path` helper is passed to the `:url` option.
To see what Rails will do with this, we look back at the output of
`bin/rails routes`:
`rails routes`:
```bash
$ bin/rails routes
$ rails routes
Prefix Verb URI Pattern Controller#Action
welcome_index GET /welcome/index(.:format) welcome#index
articles GET /articles(.:format) articles#index
@ -658,7 +658,7 @@ Rails developers tend to use when creating new models. To create the new model,
run this command in your terminal:
```bash
$ bin/rails generate model Article title:string text:text
$ rails generate model Article title:string text:text
```
With that command we told Rails that we want an `Article` model, together
@ -677,7 +677,7 @@ models, as that will be done automatically by Active Record.
### Running a Migration
As we've just seen, `bin/rails generate model` created a _database migration_ file
As we've just seen, `rails generate model` created a _database migration_ file
inside the `db/migrate` directory. Migrations are Ruby classes that are
designed to make it simple to create and modify database tables. Rails uses
rake commands to run migrations, and it's possible to undo a migration after
@ -710,10 +710,10 @@ two timestamp fields to allow Rails to track article creation and update times.
TIP: For more information about migrations, refer to [Active Record Migrations]
(active_record_migrations.html).
At this point, you can use a bin/rails command to run the migration:
At this point, you can use a rails command to run the migration:
```bash
$ bin/rails db:migrate
$ rails db:migrate
```
Rails will execute this migration command and tell you it created the Articles
@ -730,7 +730,7 @@ NOTE. Because you're working in the development environment by default, this
command will apply to the database defined in the `development` section of your
`config/database.yml` file. If you would like to execute migrations in another
environment, for instance in production, you must explicitly pass it when
invoking the command: `bin/rails db:migrate RAILS_ENV=production`.
invoking the command: `rails db:migrate RAILS_ENV=production`.
### Saving data in the controller
@ -817,7 +817,7 @@ If you submit the form again now, Rails will complain about not finding the
`show` action. That's not very useful though, so let's add the `show` action
before proceeding.
As we have seen in the output of `bin/rails routes`, the route for `show` action is
As we have seen in the output of `rails routes`, the route for `show` action is
as follows:
```
@ -879,7 +879,7 @@ Visit <http://localhost:3000/articles/new> and give it a try!
### Listing all articles
We still need a way to list all our articles, so let's do that.
The route for this as per output of `bin/rails routes` is:
The route for this as per output of `rails routes` is:
```
articles GET /articles(.:format) articles#index
@ -1376,7 +1376,7 @@ Then do the same for the `app/views/articles/edit.html.erb` view:
We're now ready to cover the "D" part of CRUD, deleting articles from the
database. Following the REST convention, the route for
deleting articles as per output of `bin/rails routes` is:
deleting articles as per output of `rails routes` is:
```ruby
DELETE /articles/:id(.:format) articles#destroy
@ -1526,7 +1526,7 @@ the `Article` model. This time we'll create a `Comment` model to hold a
reference to an article. Run this command in your terminal:
```bash
$ bin/rails generate model Comment commenter:string body:text article:references
$ rails generate model Comment commenter:string body:text article:references
```
This command will generate four files:
@ -1577,7 +1577,7 @@ for it, and a foreign key constraint that points to the `id` column of the `arti
table. Go ahead and run the migration:
```bash
$ bin/rails db:migrate
$ rails db:migrate
```
Rails is smart enough to only execute the migrations that have not already been
@ -1653,7 +1653,7 @@ With the model in hand, you can turn your attention to creating a matching
controller. Again, we'll use the same generator we used before:
```bash
$ bin/rails generate controller Comments
$ rails generate controller Comments
```
This creates five files and one empty directory:

8
guides/source/plugins.md
View file

@ -138,7 +138,7 @@ To test that your method does what it says it does, run the unit tests with `bin
To see this in action, change to the `test/dummy` directory, fire up a console, and start squawking:
```bash
$ bin/rails console
$ rails console
>> "Hello World".to_squawk
=> "squawk! Hello World"
```
@ -241,8 +241,8 @@ We can easily generate these models in our "dummy" Rails application by running
```bash
$ cd test/dummy
$ bin/rails generate model Hickwall last_squawk:string
$ bin/rails generate model Wickwall last_squawk:string last_tweet:string
$ rails generate model Hickwall last_squawk:string
$ rails generate model Wickwall last_squawk:string last_tweet:string
```
Now you can create the necessary database tables in your testing database by navigating to your dummy app
@ -250,7 +250,7 @@ and migrating the database. First, run:
```bash
$ cd test/dummy
$ bin/rails db:migrate
$ rails db:migrate
```
While you are here, change the Hickwall and Wickwall models so that they know that they are supposed to act

12
guides/source/rails_application_templates.md
View file

@ -22,11 +22,11 @@ $ rails new blog -m ~/template.rb
$ rails new blog -m http://example.com/template.rb
```
You can use the `app:template` Rake task to apply templates to an existing Rails application. The location of the template needs to be passed in via the LOCATION environment variable. Again, this can either be path to a file or a URL.
You can use the `app:template` rails command to apply templates to an existing Rails application. The location of the template needs to be passed in via the LOCATION environment variable. Again, this can either be path to a file or a URL.
```bash
$ bin/rails app:template LOCATION=~/template.rb
$ bin/rails app:template LOCATION=http://example.com/template.rb
$ rails app:template LOCATION=~/template.rb
$ rails app:template LOCATION=http://example.com/template.rb
```
Template API
@ -177,19 +177,19 @@ run "rm README.rdoc"
### rails_command(command, options = {})
Runs the supplied task in the Rails application. Let's say you want to migrate the database:
Runs the supplied command in the Rails application. Let's say you want to migrate the database:
```ruby
rails_command "db:migrate"
```
You can also run tasks with a different Rails environment:
You can also run commands with a different Rails environment:
```ruby
rails_command "db:migrate", env: 'production'
```
You can also run tasks as a super-user:
You can also run commands as a super-user:
```ruby
rails_command "log:clear", sudo: true

6
guides/source/rails_on_rack.md
View file

@ -94,10 +94,10 @@ but is built for better flexibility and more features to meet Rails' requirement
### Inspecting Middleware Stack
Rails has a handy task for inspecting the middleware stack in use:
Rails has a handy command for inspecting the middleware stack in use:
```bash
$ bin/rails middleware
$ rails middleware
```
For a freshly generated Rails application, this might produce something like:
@ -181,7 +181,7 @@ And now if you inspect the middleware stack, you'll find that `Rack::Runtime` is
not a part of it.
```bash
$ bin/rails middleware
$ rails middleware
(in /Users/lifo/Rails/blog)
use ActionDispatch::Static
use #<ActiveSupport::Cache::Strategy::LocalCache::Middleware:0x00000001c304c8>

14
guides/source/routing.md
View file

@ -1191,18 +1191,18 @@ edit_user GET /users/:id/edit(.:format) users#edit
You can search through your routes with the grep option: -g. This outputs any routes that partially match the URL helper method name, the HTTP verb, or the URL path.
```
$ bin/rails routes -g new_comment
$ bin/rails routes -g POST
$ bin/rails routes -g admin
$ rails routes -g new_comment
$ rails routes -g POST
$ rails routes -g admin
```
If you only want to see the routes that map to a specific controller, there's the -c option.
```
$ bin/rails routes -c users
$ bin/rails routes -c admin/users
$ bin/rails routes -c Comments
$ bin/rails routes -c Articles::CommentsController
$ rails routes -c users
$ rails routes -c admin/users
$ rails routes -c Comments
$ rails routes -c Articles::CommentsController
```
TIP: You'll find that the output from `rails routes` is much more readable if you widen your terminal window until the output lines don't wrap. You can also use --expanded option to turn on the expanded table formatting mode.

2
guides/source/security.md
View file

@ -1214,7 +1214,7 @@ key that's generated into a version control ignored `config/master.key` — Rail
will also look for that key in `ENV["RAILS_MASTER_KEY"]`. Rails also requires the
key to boot in production, so the credentials can be read.
To edit stored credentials use `bin/rails credentials:edit`.
To edit stored credentials use `rails credentials:edit`.
By default, this file contains the application's
`secret_key_base`, but it could also be used to store other credentials such as

66
guides/source/testing.md
View file

@ -70,7 +70,7 @@ If you remember, we used the `rails generate model` command in the
model, and among other things it created test stubs in the `test` directory:
```bash
$ bin/rails generate model article title:string body:text
$ rails generate model article title:string body:text
...
create app/models/article.rb
create test/models/article_test.rb
@ -156,7 +156,7 @@ end
Let us run this newly added test (where `6` is the number of line where the test is defined).
```bash
$ bin/rails test test/models/article_test.rb:6
$ rails test test/models/article_test.rb:6
Run options: --seed 44656
# Running:
@ -168,7 +168,7 @@ ArticleTest#test_should_not_save_article_without_title [/path/to/blog/test/model
Expected true to be nil or false
bin/rails test test/models/article_test.rb:6
rails test test/models/article_test.rb:6
@ -206,7 +206,7 @@ end
Now the test should pass. Let us verify by running the test again:
```bash
$ bin/rails test test/models/article_test.rb:6
$ rails test test/models/article_test.rb:6
Run options: --seed 31252
# Running:
@ -239,7 +239,7 @@ end
Now you can see even more output in the console from running the tests:
```bash
$ bin/rails test test/models/article_test.rb
$ rails test test/models/article_test.rb
Run options: --seed 1808
# Running:
@ -252,7 +252,7 @@ NameError: undefined local variable or method 'some_undefined_variable' for #<Ar
test/models/article_test.rb:11:in 'block in <class:ArticleTest>'
bin/rails test test/models/article_test.rb:9
rails test test/models/article_test.rb:9
@ -276,7 +276,7 @@ code. However there are situations when you want to see the full
backtrace. Set the `-b` (or `--backtrace`) argument to enable this behavior:
```bash
$ bin/rails test -b test/models/article_test.rb
$ rails test -b test/models/article_test.rb
```
If we want this test to pass we can modify it to use `assert_raises` like so:
@ -381,12 +381,12 @@ documentation](http://docs.seattlerb.org/minitest).
### The Rails Test Runner
We can run all of our tests at once by using the `bin/rails test` command.
We can run all of our tests at once by using the `rails test` command.
Or we can run a single test file by passing the `bin/rails test` command the filename containing the test cases.
Or we can run a single test file by passing the `rails test` command the filename containing the test cases.
```bash
$ bin/rails test test/models/article_test.rb
$ rails test test/models/article_test.rb
Run options: --seed 1559
# Running:
@ -404,7 +404,7 @@ You can also run a particular test method from the test case by providing the
`-n` or `--name` flag and the test's method name.
```bash
$ bin/rails test test/models/article_test.rb -n test_the_truth
$ rails test test/models/article_test.rb -n test_the_truth
Run options: -n test_the_truth --seed 43583
# Running:
@ -419,29 +419,29 @@ Finished tests in 0.009064s, 110.3266 tests/s, 110.3266 assertions/s.
You can also run a test at a specific line by providing the line number.
```bash
$ bin/rails test test/models/article_test.rb:6 # run specific test and line
$ rails test test/models/article_test.rb:6 # run specific test and line
```
You can also run an entire directory of tests by providing the path to the directory.
```bash
$ bin/rails test test/controllers # run all tests from specific directory
$ rails test test/controllers # run all tests from specific directory
```
The test runner also provides a lot of other features like failing fast, deferring test output
at the end of test run and so on. Check the documentation of the test runner as follows:
```bash
$ bin/rails test -h
Usage: bin/rails test [options] [files or directories]
$ rails test -h
Usage: rails test [options] [files or directories]
You can run a single test by appending a line number to a filename:
bin/rails test test/models/user_test.rb:27
rails test test/models/user_test.rb:27
You can run multiple files and directories at the same time:
bin/rails test test/controllers test/integration/login_test.rb
rails test test/controllers test/integration/login_test.rb
By default test failures and errors are reported inline during a run.
@ -490,7 +490,7 @@ parallelize your local test suite differently from your CI, so an environment va
to be able to easily change the number of workers a test run should use:
```
PARALLEL_WORKERS=15 bin/rails test
PARALLEL_WORKERS=15 rails test
```
When parallelizing tests, Active Record automatically handles creating and migrating a database for each
@ -543,7 +543,7 @@ want to parallelize your local test suite differently from your CI, so an enviro
to be able to easily change the number of workers a test run should use:
```
PARALLEL_WORKERS=15 bin/rails test
PARALLEL_WORKERS=15 rails test
```
The Test Database
@ -563,11 +563,11 @@ structure. The test helper checks whether your test database has any pending
migrations. It will try to load your `db/schema.rb` or `db/structure.sql`
into the test database. If migrations are still pending, an error will be
raised. Usually this indicates that your schema is not fully migrated. Running
the migrations against the development database (`bin/rails db:migrate`) will
the migrations against the development database (`rails db:migrate`) will
bring the schema up to date.
NOTE: If there were modifications to existing migrations, the test database needs to
be rebuilt. This can be done by executing `bin/rails db:test:prepare`.
be rebuilt. This can be done by executing `rails db:test:prepare`.
### The Low-Down on Fixtures
@ -680,7 +680,7 @@ Rails model tests are stored under the `test/models` directory. Rails provides
a generator to create a model test skeleton for you.
```bash
$ bin/rails generate test_unit:model article title:string body:text
$ rails generate test_unit:model article title:string body:text
create test/models/article_test.rb
create test/fixtures/articles.yml
```
@ -697,7 +697,7 @@ For creating Rails system tests, you use the `test/system` directory in your
application. Rails provides a generator to create a system test skeleton for you.
```bash
$ bin/rails generate system_test users
$ rails generate system_test users
invoke test_unit
create test/system/users_test.rb
```
@ -798,7 +798,7 @@ created for you. If you didn't use the scaffold generator, start by creating a
system test skeleton.
```bash
$ bin/rails generate system_test articles
$ rails generate system_test articles
```
It should have created a test file placeholder for us. With the output of the
@ -827,11 +827,11 @@ The test should see that there is an `h1` on the articles index page and pass.
Run the system tests.
```bash
bin/rails test:system
rails test:system
```
NOTE: By default, running `bin/rails test` won't run your system tests.
Make sure to run `bin/rails test:system` to actually run them.
NOTE: By default, running `rails test` won't run your system tests.
Make sure to run `rails test:system` to actually run them.
#### Creating articles system test
@ -910,7 +910,7 @@ Integration tests are used to test how various parts of your application interac
For creating Rails integration tests, we use the `test/integration` directory for our application. Rails provides a generator to create an integration test skeleton for us.
```bash
$ bin/rails generate integration_test user_flows
$ rails generate integration_test user_flows
exists test/integration/
create test/integration/user_flows_test.rb
```
@ -946,7 +946,7 @@ Let's add an integration test to our blog application. We'll start with a basic
We'll start by generating our integration test skeleton:
```bash
$ bin/rails generate integration_test blog_flow
$ rails generate integration_test blog_flow
```
It should have created a test file placeholder for us. With the output of the
@ -1034,7 +1034,7 @@ You should test for things such as:
The easiest way to see functional tests in action is to generate a controller using the scaffold generator:
```bash
$ bin/rails generate scaffold_controller article title:string body:text
$ rails generate scaffold_controller article title:string body:text
...
create app/controllers/articles_controller.rb
...
@ -1050,7 +1050,7 @@ If you already have a controller and just want to generate the test scaffold cod
each of the seven default actions, you can use the following command:
```bash
$ bin/rails generate test_unit:scaffold article
$ rails generate test_unit:scaffold article
...
invoke test_unit
create test/controllers/articles_controller_test.rb
@ -1225,7 +1225,7 @@ end
If we run our test now, we should see a failure:
```bash
$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
$ rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 32266
# Running:
@ -1263,7 +1263,7 @@ end
Now if we run our tests, we should see it pass:
```bash
$ bin/rails test test/controllers/articles_controller_test.rb -n test_should_create_article
$ rails test test/controllers/articles_controller_test.rb -n test_should_create_article
Run options: -n test_should_create_article --seed 18981
# Running:

16
guides/source/upgrading_ruby_on_rails.md
View file

@ -45,8 +45,8 @@ TIP: Ruby 1.8.7 p248 and p249 have marshaling bugs that crash Rails. Ruby Enterp
### The Update Task
Rails provides the `app:update` task (`rake rails:update` on 4.2 and earlier). After updating the Rails version
in the `Gemfile`, run this task.
Rails provides the `app:update` command (`rake rails:update` on 4.2 and earlier). After updating the Rails version
in the `Gemfile`, run this command.
This will help you with the creation of new files and changes of old files in an
interactive session.
@ -85,7 +85,7 @@ For more information on changes made to Rails 5.2 please see the [release notes]
### Bootsnap
Rails 5.2 adds bootsnap gem in the [newly generated app's Gemfile](https://github.com/rails/rails/pull/29313).
The `app:update` task sets it up in `boot.rb`. If you want to use it, then add it in the Gemfile,
The `app:update` command sets it up in `boot.rb`. If you want to use it, then add it in the Gemfile,
otherwise change the `boot.rb` to not use bootsnap.
### Expiry in signed or encrypted cookie is now embedded in the cookies values
@ -257,16 +257,18 @@ it.
`debugger` is not supported by Ruby 2.2 which is required by Rails 5. Use `byebug` instead.
### Use bin/rails for running tasks and tests
### Use `rails` for running tasks and tests
Rails 5 adds the ability to run tasks and tests through `bin/rails` instead of rake. Generally
these changes are in parallel with rake, but some were ported over altogether.
these changes are in parallel with rake, but some were ported over altogether. As the `rails`
command already looks for and runs `bin/rails`, we recommend you to use the shorter `rails`
over `bin/rails.
To use the new test runner simply type `bin/rails test`.
To use the new test runner simply type `rails test`.
`rake dev:cache` is now `rails dev:cache`.
Run `bin/rails` to see the list of commands available.
Run `rails` inside your application's directory to see the list of commands available.
### `ActionController::Parameters` No Longer Inherits from `HashWithIndifferentAccess`

2
railties/lib/rails/application.rb
View file

@ -444,7 +444,7 @@ module Rails
# Shorthand to decrypt any encrypted configurations or files.
#
# For any file added with <tt>bin/rails encrypted:edit</tt> call +read+ to decrypt
# For any file added with <tt>rails encrypted:edit</tt> call +read+ to decrypt
# the file with the master key.
# The master key is either stored in +config/master.key+ or <tt>ENV["RAILS_MASTER_KEY"]</tt>.
#

2
railties/lib/rails/command/base.rb
View file

@ -70,7 +70,7 @@ module Rails
end
def executable
"bin/rails #{command_name}"
"rails #{command_name}"
end
# Use Rails' default banner.

2
railties/lib/rails/commands/credentials/USAGE
View file

@ -14,7 +14,7 @@ that just contains the secret_key_base used by MessageVerifiers/MessageEncryptor
signing and encrypting cookies.
For applications created prior to Rails 5.2, we'll automatically generate a new
credentials file in `config/credentials.yml.enc` the first time you run `bin/rails credentials:edit`.
credentials file in `config/credentials.yml.enc` the first time you run `rails credentials:edit`.
If you didn't have a master key saved in `config/master.key`, that'll be created too.
Don't lose this master key! Put it in a password manager your team can access.

4
railties/lib/rails/commands/credentials/credentials_command.rb
View file

@ -69,9 +69,9 @@ module Rails
def missing_credentials_message
if Rails.application.credentials.key.nil?
"Missing master key to decrypt credentials. See bin/rails credentials:help"
"Missing master key to decrypt credentials. See `rails credentials:help`"
else
"No credentials have been added yet. Use bin/rails credentials:edit to change that."
"No credentials have been added yet. Use `rails credentials:edit` to change that."
end
end
end

4
railties/lib/rails/commands/encrypted/encrypted_command.rb
View file

@ -76,9 +76,9 @@ module Rails
def missing_encrypted_message(key:, key_path:, file_path:)
if key.nil?
"Missing '#{key_path}' to decrypt data. See bin/rails encrypted:help"
"Missing '#{key_path}' to decrypt data. See `rails encrypted:help`"
else
"File '#{file_path}' does not exist. Use bin/rails encrypted:edit #{file_path} to change that."
"File '#{file_path}' does not exist. Use `rails encrypted:edit #{file_path}` to change that."
end
end
end

6
railties/lib/rails/commands/secrets/USAGE
View file

@ -7,7 +7,7 @@ with the code.
=== Setup
Run `bin/rails secrets:setup` to opt in and generate the `config/secrets.yml.key`
Run `rails secrets:setup` to opt in and generate the `config/secrets.yml.key`
and `config/secrets.yml.enc` files.
The latter contains all the keys to be encrypted while the former holds the
@ -45,12 +45,12 @@ the key. Add this:
config.read_encrypted_secrets = true
to the environment you'd like to read encrypted secrets. `bin/rails secrets:setup`
to the environment you'd like to read encrypted secrets. `rails secrets:setup`
inserts this into the production environment by default.
=== Editing Secrets
After `bin/rails secrets:setup`, run `bin/rails secrets:edit`.
After `rails secrets:setup`, run `rails secrets:edit`.
That command opens a temporary file in `$EDITOR` with the decrypted contents of
`config/secrets.yml.enc` to edit the encrypted secrets.

4
railties/lib/rails/commands/secrets/secrets_command.rb
View file

@ -22,7 +22,7 @@ module Rails
if ENV["EDITOR"].to_s.empty?
say "No $EDITOR to open decrypted secrets in. Assign one like this:"
say ""
say %(EDITOR="mate --wait" bin/rails secrets:edit)
say %(EDITOR="mate --wait" rails secrets:edit)
say ""
say "For editors that fork and exit immediately, it's important to pass a wait flag,"
say "otherwise the secrets will be saved immediately with no chance to edit."
@ -56,7 +56,7 @@ module Rails
private
def deprecate_in_favor_of_credentials_and_exit
say "Encrypted secrets is deprecated in favor of credentials. Run:"
say "bin/rails credentials:help"
say "rails credentials:help"
exit 1
end

2
railties/lib/rails/generators/rails/app/app_generator.rb
View file

@ -249,7 +249,7 @@ module Rails
add_shared_options_for "application"
# Add bin/rails options
# Add rails command options
class_option :version, type: :boolean, aliases: "-v", group: :rails,
desc: "Show Rails version number and quit"

6
railties/lib/rails/generators/rails/app/templates/bin/update.tt
View file

@ -23,12 +23,12 @@ chdir APP_ROOT do
<% unless options.skip_active_record? -%>
puts "\n== Updating database =="
system! 'bin/rails db:migrate'
system! 'rails db:migrate'
<% end -%>
puts "\n== Removing old logs and tempfiles =="
system! 'bin/rails log:clear tmp:clear'
system! 'rails log:clear tmp:clear'
puts "\n== Restarting application server =="
system! 'bin/rails restart'
system! 'rails restart'
end

2
railties/lib/rails/generators/rails/credentials/credentials_generator.rb
View file

@ -20,7 +20,7 @@ module Rails
add_credentials_file_silently(template)
say "You can edit encrypted credentials with `bin/rails credentials:edit`."
say "You can edit encrypted credentials with `rails credentials:edit`."
say ""
end
end

2
railties/lib/rails/test_unit/reporter.rb
View file

@ -5,7 +5,7 @@ require "minitest"
module Rails
class TestUnitReporter < Minitest::StatisticsReporter
class_attribute :executable, default: "bin/rails test"
class_attribute :executable, default: "rails test"
def record(result)
super

4
railties/test/application/test_runner_test.rb
View file

@ -504,7 +504,7 @@ module ApplicationTests
create_test_file :models, "post", pass: false, print: false
output = run_test_command("test/models/post_test.rb")
expect = %r{Running:\n\nF\n\nFailure:\nPostTest#test_truth \[[^\]]+test/models/post_test.rb:6\]:\nwups!\n\nbin/rails test test/models/post_test.rb:4\n\n\n\n}
expect = %r{Running:\n\nF\n\nFailure:\nPostTest#test_truth \[[^\]]+test/models/post_test.rb:6\]:\nwups!\n\nrails test test/models/post_test.rb:4\n\n\n\n}
assert_match expect, output
end
@ -553,7 +553,7 @@ module ApplicationTests
create_test_file :models, "account"
create_test_file :models, "post", pass: false
# This specifically verifies TEST for backwards compatibility with rake test
# as bin/rails test already supports running tests from a single file more cleanly.
# as `rails test` already supports running tests from a single file more cleanly.
output = Dir.chdir(app_path) { `bin/rake test TEST=test/models/post_test.rb` }
assert_match "PostTest", output, "passing TEST= should run selected test"

2
railties/test/commands/credentials_test.rb
View file

@ -15,7 +15,7 @@ class Rails::Command::CredentialsCommandTest < ActiveSupport::TestCase
test "edit without editor gives hint" do
run_edit_command(editor: "").tap do |output|
assert_match "No $EDITOR to open file in", output
assert_match "bin/rails credentials:edit", output
assert_match "rails credentials:edit", output
end
end

4
railties/test/commands/dbconsole_test.rb
View file

@ -265,14 +265,14 @@ class Rails::DBConsoleTest < ActiveSupport::TestCase
stdout = capture(:stdout) do
Rails::Command.invoke(:dbconsole, ["-h"])
end
assert_match(/bin\/rails dbconsole \[environment\]/, stdout)
assert_match(/rails dbconsole \[environment\]/, stdout)
end
def test_print_help_long
stdout = capture(:stdout) do
Rails::Command.invoke(:dbconsole, ["--help"])
end
assert_match(/bin\/rails dbconsole \[environment\]/, stdout)
assert_match(/rails dbconsole \[environment\]/, stdout)
end
attr_reader :aborted, :output

2
railties/test/commands/encrypted_test.rb
View file

@ -14,7 +14,7 @@ class Rails::Command::EncryptedCommandTest < ActiveSupport::TestCase
test "edit without editor gives hint" do
run_edit_command("config/tokens.yml.enc", editor: "").tap do |output|
assert_match "No $EDITOR to open file in", output
assert_match "bin/rails encrypted:edit", output
assert_match "rails encrypted:edit", output
end
end

2
railties/test/generators/test_runner_in_engine_test.rb
View file

@ -19,7 +19,7 @@ class TestRunnerInEngineTest < ActiveSupport::TestCase
create_test_file "post", pass: false
output = run_test_command("test/post_test.rb")
expect = %r{Running:\n\nPostTest\nF\n\nFailure:\nPostTest#test_truth \[[^\]]+test/post_test\.rb:6\]:\nwups!\n\nbin/rails test test/post_test\.rb:4}
expect = %r{Running:\n\nPostTest\nF\n\nFailure:\nPostTest#test_truth \[[^\]]+test/post_test\.rb:6\]:\nwups!\n\nrails test test/post_test\.rb:4}
assert_match expect, output
end

10
railties/test/test_unit/reporter_test.rb
View file

@ -18,7 +18,7 @@ class TestUnitReporterTest < ActiveSupport::TestCase
@reporter.record(failed_test)
@reporter.report
assert_match %r{^bin/rails test .*test/test_unit/reporter_test\.rb:\d+$}, @output.string
assert_match %r{^rails test .*test/test_unit/reporter_test\.rb:\d+$}, @output.string
assert_rerun_snippet_count 1
end
@ -64,7 +64,7 @@ class TestUnitReporterTest < ActiveSupport::TestCase
@reporter.record(failed_test)
@reporter.report
expect = %r{\AF\n\nFailure:\nTestUnitReporterTest::ExampleTest#woot \[[^\]]+\]:\nboo\n\nbin/rails test test/test_unit/reporter_test\.rb:\d+\n\n\z}
expect = %r{\AF\n\nFailure:\nTestUnitReporterTest::ExampleTest#woot \[[^\]]+\]:\nboo\n\nrails test test/test_unit/reporter_test\.rb:\d+\n\n\z}
assert_match expect, @output.string
end
@ -72,7 +72,7 @@ class TestUnitReporterTest < ActiveSupport::TestCase
@reporter.record(errored_test)
@reporter.report
expect = %r{\AE\n\nError:\nTestUnitReporterTest::ExampleTest#woot:\nArgumentError: wups\n \n\nbin/rails test .*test/test_unit/reporter_test\.rb:\d+\n\n\z}
expect = %r{\AE\n\nError:\nTestUnitReporterTest::ExampleTest#woot:\nArgumentError: wups\n \n\nrails test .*test/test_unit/reporter_test\.rb:\d+\n\n\z}
assert_match expect, @output.string
end
@ -81,7 +81,7 @@ class TestUnitReporterTest < ActiveSupport::TestCase
verbose.record(skipped_test)
verbose.report
expect = %r{\ATestUnitReporterTest::ExampleTest#woot = 10\.00 s = S\n\n\nSkipped:\nTestUnitReporterTest::ExampleTest#woot \[[^\]]+\]:\nskipchurches, misstemples\n\nbin/rails test test/test_unit/reporter_test\.rb:\d+\n\n\z}
expect = %r{\ATestUnitReporterTest::ExampleTest#woot = 10\.00 s = S\n\n\nSkipped:\nTestUnitReporterTest::ExampleTest#woot \[[^\]]+\]:\nskipchurches, misstemples\n\nrails test test/test_unit/reporter_test\.rb:\d+\n\n\z}
assert_match expect, @output.string
end
@ -159,7 +159,7 @@ class TestUnitReporterTest < ActiveSupport::TestCase
private
def assert_rerun_snippet_count(snippet_count)
assert_equal snippet_count, @output.string.scan(%r{^bin/rails test }).size
assert_equal snippet_count, @output.string.scan(%r{^rails test }).size
end
def failed_test