| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 9712a7a12b7f9e4dcef751ceda8a73c3f4beb11f, reversing
changes made to 3e65c3d3886336e9145438cdeacaf4ebec6a48b8.
Reverting because this caused test failures and while we have a followup
branch there is still one failure that happens randomly and isn't
straight forward to fix.
|
|\ \
| | |
| | | |
Controller generators should be creating IntegrationTest stubs instea…
|
| | |
| | |
| | |
| | | |
ControllerTest
|
|\ \ \ |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | | |
Prevent a 500 in the default controller scaffold
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If you update a record with no attributes, you'll hit a 500 from a guard
in `assign_attributes` raising:
```ruby
ArgumentError: When assigning attributes, you must pass a hash as an argument.
app/controllers/users_controller.rb:44:in `block in update'
app/controllers/users_controller.rb:43:in `update'
test/controllers/users_controller_test.rb:37:in `block in <class:UsersControllerTest>'
```
Not a biggie, but may be quite confusing for the folks new to the
framework.
|
|\ \ \
| | | |
| | | | |
Update web-console to 3.0.0
|
| |/ /
| | |
| | |
| | |
| | | |
Web Console 3.0.0 is compatible with Rails 5, while the 2.x.x releases
aren't.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The API isn't ready yet, which means we haven't documented it.
People can't make their own commands, so there's no reason to show it
in generated documentation.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before this commit, the sole presence of the Listen constant
enabled the evented file watcher (unless listen resorted to
the polling backend).
This way, applications may depend on listen for other stuff
independently of this feature. Also, allows teams with mixed
setups to decide at boot time whether the evented watcher
should be enabled for each particular instance.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since the absolute path is not required to re-run the test,
modified so that unnecessary information is not displayed.
```ruby
# before
bin/rails test /path/to/blorgh/test/integration/navigation_test.rb:5
# after
bin/rails test test/integration/navigation_test.rb:5
```
|
| | |
|
| | |
|
| |
| |
| |
| | |
is the default value for only API apps
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
behavior
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
The exit status code was not set when tests were fired with `rake`.
Now, it is being set and it matches behavior of running tests via `rails`
command (`rails test`), so no matter if `rake test` or `rails test` command
is used the exit code will be set.
|
| |
| |
| |
| |
| | |
We had 2 pull requests erronously trying to remove the first command.
Add some comments for clarity.
|
|\ \
| | |
| | |
| | |
| | | |
y-yagi/remove_request_forgery_protection_from_rails_api
remove `request_forgery_protection` initializer from rails api
|
| | |
| | |
| | |
| | |
| | | |
In rails api, since default is so as not to use the `protect_from_forgery`,
`request_forgery_protection` initializer I think that's unnecessary
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Railsties tests are broken with this new update checker so we will use
the old one until we have the tests fixed.
|
| | |
| | |
| | |
| | | |
Related with e62ddac05b7d827ae870898d7cd9eaf76e0730aa
|
| | |
| | |
| | |
| | | |
Related with 668c006cf33a63ac3f8a8f064c772a339341e70c.
|
|/ / |
|
|\ \
| | |
| | | |
Fix failing test using custom file watcher
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
LoadingTest#test_does_not_reload_constants_on_development_if_custom_file_watcher_always_returns_false in railties/test/application/loading_test.rb is failing with: `NoMethodError: undefined method 'execute' for #<#<Class:0x00000002465a30>:0x00000001f79698>`
The test creates an anonymous class to be used as a custom file watcher using `config.file_watcher=`. Per the Rails guides for Configuring, the class set to `config.file_watcher` “Must conform to ActiveSupport::FileUpdateChecker API”. Per the docs for ActiveSupport::FileUpdateChecker, the API depends on four methods: #initialize, #updated?, #execute, and #execute_if_updated. The custom file watcher in the failing test only implements the first two methods.
This pull request adds #execute and #execute_if_updated to the custom file_watcher, conforming it to the ActiveSupport::FileUpdateChecker API, and passing the test.
|
|/ /
| |
| |
| |
| | |
This reverts commit 5a0e0e72995472e315738dcea5b5a12d6e3d3489.
This commit causes railties tests on TravisCI to always return a 0 status (all tests passing), even when tests are failing. Reverting for now until a new solution can be found.
|