| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
If use rails together with `spring`, `spring` is rewrite `$0` in the interior
command name. Therefore, for `$0` correct command name does not appear, `$0` has
been modified so that it does not use.
|
|
|
|
|
|
|
| |
The default is that's false, caching even if you do not specify the caching option is determined not to use,
and `tmp/caching-dev.txt` will be deleted.
If it is this, regardless of whether or not there is `tmp/caching-dev.txt`, be sure to order would be necessary to specify the caching option,
I think that in than good to so as not to do anything by default.
|
|
|
|
|
| |
Lets have the server and the Rake task go through the same ropes, so we can
share all the file lookup, adding, and deleting code.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix bug (#22811) that occurs when rails server is started in daemon mode
and optional path to the `server.pid` file is omitted. Store default path
in a constant instead of evaluating it multiple time using `File.expand_path`.
The bug in detail: The server startup procedure crashes, since it tries to
open a file at `/tmp/pids/server.pid` instead of
`<path to project>/tmp/pids/server.pid`. This bug was introduced in 51211a94bd
when Rack was upgraded from version 1.x to 2.x. Since version 2.x,
Rack does not memoize the options hash [1], and as a consequence
`Rails::Server#default_options` will be evaluated multiple times.
The hash returned by `Rails::Server#default_options` holds the default path
to the `server.pid` file. The path is generated with the method
`File.expand_path`. However, the return value of this method depends on the
current working directory [2], which changes once `Process.daemon` is invoked
by `Rack::Server#daemonize_app` and the process is detached from the current
shell.
Close #22811
[1]https://git.io/vzen2
[2]http://ruby-doc.org/core-2.1.5/File.html#method-c-expand_path
|
|\
| |
| | |
[close #22917] Don't output to `STDOUT` twice
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When `rails console` or `rails server` are used along with a logger set to output to `STDOUT` then the contents will show up twice. This happens because the logger is extended with `ActiveSupportLogger.broadcast` with a destination of STDOUT even if it is already outputting to `STDOUT`.
Previously PR #22592 attempted to fix this issue, but it ended up causing NoMethodErrors. A better approach than relying on adding a method and flow control is to inspect the log destination directly. For this `ActiveSupport::Logger.logger_outputs_to?` was introduced
```ruby
logger = Logger.new(STDOUT)
ActiveSupport::Logger.logger_outputs_to?(logger, STDOUT)
# => true
```
To accomplish this we must look inside of an instance variable of standard lib's Logger `@logdev`. There is a related Ruby proposal to expose this method in a standard way: https://bugs.ruby-lang.org/issues/11955
|
|/
|
|
| |
Add tests for detecting bad options for runner
|
|\ |
|
|/
|
|
|
|
|
| |
Allows any Rake task to be run through `bin/rails` such as `bin/rails db:migrate`,
`bin/rails notes` etc.
The Rake tasks are appended to Rails' help output, and blend in as standard commands.
|
| |
|
|
|
|
|
|
|
| |
Reading `Rails::Commands::Command` feels excessive. Especially if users can subclass command
to write their own commands — which I'd like to aim for.
Switch to `Rails::Command` before we get too far into things.
|
|
|
|
|
|
|
| |
We should first attempt to run commands through Rails command, and then
fall back to trying the commands tasks.
Because eventually the commands tasks should be their own commands.
|
|
|
|
|
|
|
|
|
| |
When attempting to run a `rake` task with `bin/rails`, Rails would see
check that a Rake task existed and ask users if they meant to run it with
rake.
We don't need that anymore, as the goal is to have `rails` be a valid way
to run rake tasks.
|
|
|
|
|
|
|
|
|
|
|
|
| |
The class level version is responsible for changing a task name to
command name, then finding a command and run it if there is one.
The instance level `run` then makes sure arguments have been parsed
into `@options` and runs the command by sending it.
`Rails::Commands::Command.run` returns true to make it work within
`Rails::CommandsTask`, but won't in the future when it handles
all option parsing.
|
|
|
|
|
|
|
|
| |
When `parse_options_for` was called for a command that
hadn't set up any option parsing with `options_for`, the `call` method
would be sent to `-> {}`, which didn't like to be passed two arguments.
Switch to `proc {}` which can accept several arguments.
|
|
|
|
|
| |
I want to streamline the wording around `command`, and not
start pondering about instances.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The `ARGV` constant in Ruby is not a string, it's an array as demonstrated
by running:
```
$ ruby -e "p ARGV"
=> []
$
$ ruby -e "p ARGV" test/file.rb --version=2
=> ["test/file.rb", "--version=2"]
```
|
|
|
|
|
|
| |
* Ditch the instance methods local variable.
* Prefer Ruby's default nil return, and remove else branch.
|
|
|
|
|
|
|
|
| |
Checking that a command exists before running it is an implementation detail
of the Rails command and Rake task world right now.
Eventually I'd like to get rid of `exists?`, when I've worked out another way
to fall back to run the old tasks.
|
|
|
|
|
| |
Users shouldn't have to lookup the command name for a task. Put it in
the private section, so it doesn't show up in any generated documentation.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Taken from @Sonopa's commits on PR #19091.
Add support for dev caching via "rails s" flags.
Implement suggestions from @kaspth.
Remove temporary cache file if server does not have flags.
Break at 80 characters in railties/CHANGELOG.md
Remove ability to disable cache based on server options.
Add more comprehensive options: --dev-caching / --no-dev-caching
|
| |
|
|
|
|
| |
constant loading should be thread safe now, so lets remove this
|
|
|
|
| |
Fixes #20345.
|
|
|
|
|
| |
ContentLength is not part of the rack SPEC since rack/rack@86ddc7a6ec68d7b6951c2dbd07947c4254e8bc0d
If you want it, just add it as a middleware in your config.
|
|
|
|
|
|
|
|
|
|
|
| |
This also adds free mix and matching of directories, files and lines filters.
Like so:
bin/rails test models/post_test.rb test/integration models/person_test.rb:26
You can also mix in a traditional Minitest filter:
bin/rails test test/integration -n /check_it_out/
|
|
|
|
| |
fix minor convention problems
|
|
|
|
|
|
| |
Support for versions of SQLite less than 3 was removed in #6011 as part
of the Rails 4.0 release. Therefore there is no need to have support for
it in the `rails dbconsole` command anymore.
|
|
|
|
|
|
| |
We only want to support adapters that we officially support through the
entire framework so it is better to not ask patches for adapters that
we may not support
|
| |
|
|
|
|
|
|
|
| |
Preserving RACK_ENV behavior.
This reverts commit 7bdc7635b885e473f6a577264fd8efad1c02174f, reversing
changes made to 45786be516e13d55a1fca9a4abaddd5781209103.
|
|\
| |
| | |
Don't fallback to RACK_ENV when RAILS_ENV is not present
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
| |
With refactors to Rails::Sever from v3 to v4, this method is no longer used and is untested.
Previous usage: https://github.com/rails/rails/blob/3-2-stable/railties/lib/rails/commands/server.rb#L79
Currently set from: https://github.com/rails/rails/blob/7b75551a1a4539876f878f37a2439cd02f89d961/railties/lib/rails/application/configuration.rb#L69
|
|
|
|
| |
ref: https://github.com/rails/rails/pull/18763#issuecomment-72349769
|
|\
| |
| | |
Use EXEEXT
|
| |
| |
| |
| |
| |
| |
| |
| | |
Use the configured variable EXEEXT, instead of hardcoded suffix and
platform names.
And on such platforms, files which do not end with the suffix are not
executable, so the original names are not necessary, in general.
|
|/ |
|