| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
|
|
|
|
| |
Any flags that got set will be passed through to MiniTest::Unit.runner,
such as `-n`, `-s-, and `-v`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
To run the whole test suite:
$ rails test
To run the test file(s):
$ rails test test/unit/foo_test.rb [test/unit/bar_test.rb ...]
To run the test suite
$ rails test [models,helpers,units,controllers,mailers,...]
For more information, see `rails test --help`.
This command will eventually replacing `rake test:*`, and `rake test`
command will actually invoking `rails test` instead.
|
| |
|
|
|
|
| |
Executable scripts are versioned code like the rest of your app. To generate a stub for a bundled gem: 'bundle binstubs unicorn' and 'git add bin/unicorn'
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Sometimes, on Mac OS X, programmers accidentally press Option+Space
rather than just Space and don’t see the difference. The problem is
that Option+Space writes a non-breaking space (0XA0) rather than a
normal space (0x20).
This commit removes all the non-breaking spaces inadvertently
introduced in the comments of the code.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Developers from all levels will accidentally run rake tasks using the `rails` keyword when they meant to use `rake`. Often times beginners struggle with the difference between the tools. The most common example would be `$ rails db:migrate`
Rather than telling the developer simply that they did not use a valid rails command, we can see if it was a valid rake command first. If it is a valid rake command we can auto execute it giving the user a period of time to cancel if that isn't what they intended.
Here is what `rake db:migrate` would look like if you cancel the command:
```sh
$ rails db:migrate
Assuming you meant: $ rake db:migrate
press any key to cancel in 3 seconds
>
command terminated ...
```
Here is what it looks like if you don't cancel the command:
```sh
$ rails db:migrate
Assuming you meant: $ rake db:migrate
press any key to cancel in 3 seconds
>
Running: $ rake db:migrate
== Foo: migrating ============================================================
== Foo: migrated (0.0000s) ===================================================
```
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
|
|
|
| |
Allow hyphens in environment names again.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
* Added destroy alias to rails generator
* add alias info for destroy command
* Updated command line guides
|
|
|
|
| |
like -h.
|
|\
| |
| | |
Fix engine's generator
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
| |
After a long list of discussion about the performance problem from using varargs and the reason that we can't find a great pair for it, it would be best to remove support for it for now.
It will come back if we can find a good pair for it. For now, Bon Voyage, `#among?`.
|
|
|
|
| |
suggestion!
|
|
|
|
| |
There're a lot of places in Rails source code which make a lot of sense to switching to Object#in? or Object#either? instead of using [].include?.
|
| |
|
|
|
|
| |
properly detect the failure.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
rails new APP_PATH [options]
Options:
-G, [--skip-git] # Skip Git ignores and keeps
-r, [--ruby=PATH] # Path to the Ruby binary of your choice
# Default: /Users/drogus/.rvm/rubies/ruby-1.8.7-p302/bin/ruby
-b, [--builder=BUILDER] # Path to an application builder (can be a filesystem path or URL)
[--edge] # Setup the application with Gemfile pointing to Rails repository
[--dev] # Setup the application with Gemfile pointing to your Rails checkout
[--skip-gemfile] # Don't create a Gemfile
-d, [--database=DATABASE] # Preconfigure for selected database (options: mysql/oracle/postgresql/sqlite3/frontbase/ibm_db)
# Default: sqlite3
-O, [--skip-active-record] # Skip Active Record files
-m, [--template=TEMPLATE] # Path to an application template (can be a filesystem path or URL)
-J, [--skip-prototype] # Skip Prototype files
-T, [--skip-test-unit] # Skip Test::Unit files
Runtime options:
-s, [--skip] # Skip files that already exist
-p, [--pretend] # Run but do not make any changes
-f, [--force] # Overwrite files that already exist
-q, [--quiet] # Supress status output
Rails options:
-v, [--version] # Show Rails version number and quit
-h, [--help] # Show this help message and quit
Description:
The 'rails new' command creates a new Rails application with a default
directory structure and configuration at the path you specify.
Example:
rails new ~/Code/Ruby/weblog
This generates a skeletal Rails installation in ~/Code/Ruby/weblog.
See the README in the newly created application to get going. command
|
| |
|
| |
|
|
|
|
| |
only if config.ru is not present in current dir
|
|
|
|
|
|
|
|
| |
After that commit, developers can set ENGINE_PATH in ENGINE/scripts/rails
file and load application's ./script/rails (most of the time it will be
dummy application used for testing). When running ./script/rails g it will
use application to boot up, but then it will use Engine's root and
configuration for generators.
|
|
|
|
|
|
| |
available standards support. This ensures that IE doesn't go into quirks mode because it has been blacklisted by too many users pressing the incompatible button. It also tells IE to use the ChromeFrame renderer, if the user has installed the plugin.
This guarantees that the best available standards support will be used on the client.
|
|
|
|
| |
Your application should *always* reference your application const (as Blog::Application) and Rails.application should be used just internally.
|
|
|
|
|
|
|
|
|
|
| |
Also removed the limitation of not being able to call your new server any of
the rails commands (generate, server, dbconsole, console etc) as there is
no longer any ambiguity here.
http://rails.lighthouseapp.com/projects/8994/tickets/4665
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
| |
|
|
|
|
| |
initializing the application on its own. This fixes [#4492 state:resolved] and also avoids the application being initialized twice in some rake tasks.
|
| |
|
|
|
|
|
|
| |
status:resolved]"
This reverts commit 16846553b8866eab2aa3b128a2a23a221a25f7e3.
|
|
|
|
| |
status:resolved]
|
|
|
|
| |
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
|
|
|
| |
application) and use Rails::Application.root instead of ROOT_PATH.
|
| |
|
| |
|
| |
|
|
|
|
| |
update .gitignores.
|
|
|