| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| |
| |
| |
| | |
to change that in config/environments/production.rb
|
| | |
|
| |
| |
| |
| | |
Indeed we need this to be an engine for the internal assets to work
|
| | |
|
| | |
|
| |
| |
| |
| | |
That would make possible to use it with action cable configuration.
|
|\| |
|
| |
| |
| |
| |
| |
| |
| |
| | |
Apart from specific versioning support, our tests should focus on the
behaviour of whatever version they're accompanying, regardless of when
they were written.
Application code should *not* do this.
|
| | |
|
| |
| |
| |
| | |
Rahm Emanuel doesn't deserve to be in Rails.
|
| |
| |
| |
| | |
Otherwise assets will not work
|
| | |
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
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.
|