mirror of
https://github.com/rails/rails.git
synced 2022-11-09 12:12:34 -05:00
Merge pull request #33229 from albertoalmagro/albertoalmagro/prefer-rails-command-over-bin-rails
Prefer rails command over bin/rails
This commit is contained in:
commit
ec387c6dd9
46 changed files with 301 additions and 304 deletions
|
@ -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>
|
||||
|
||||
|
|
|
@ -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" %>
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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?
|
||||
|
|
|
@ -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,
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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"]
|
||||
```
|
||||
|
||||
|
@ -472,7 +472,7 @@ default it contains:
|
|||
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 **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).
|
||||
|
@ -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!
|
||||
```
|
||||
|
||||
|
|
|
@ -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.
|
||||
```
|
||||
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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"}}
|
||||
```
|
||||
|
||||
|
|
|
@ -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`:
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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>
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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:
|
||||
|
|
|
@ -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`
|
||||
|
||||
|
|
|
@ -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>.
|
||||
#
|
||||
|
|
|
@ -70,7 +70,7 @@ module Rails
|
|||
end
|
||||
|
||||
def executable
|
||||
"bin/rails #{command_name}"
|
||||
"rails #{command_name}"
|
||||
end
|
||||
|
||||
# Use Rails' default banner.
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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.
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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"
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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"
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
||||
|
|
|
@ -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
|
||||
|
|
Loading…
Reference in a new issue