| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
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.
|
| | |
|
| | |
|
| |
| |
| |
| | |
See https://github.com/rails/rails/commit/14b20ce9b38314943dcaf73b8dab7508b70ba487.
|
|\ \
| | |
| | |
| | |
| | | |
Add option to verify Origin header in CSRF checks
[Jeremy Daer + Rafael Mendonça França]
|
| | | |
|
|\ \ \
| | | |
| | | | |
Remove <br> from scaffold form, in favor of using CSS
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
do not show Active Job test generator
|
| | |/
| |/|
| | |
| | |
| | | |
Like the other generator, for also Active Job, I think that there is no need to
display for test generator.
|
|\ \ \
| | | |
| | | | |
Remove a blank line from a template for plugin `routes.rb`
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Move the desc one level up
|
| | |/ /
| |/| |
| | | | |
Make the task visible (from rake -T) by moving the desc one level up
|
|\ \ \ \
| |_|/ /
|/| | | |
don't package test files in plugin gemspec
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
In rails engine, there is a dummy application under test,
the size of the test file is increased.
However, there is no need test files for most users,
I think it good to have so as not included by default.
|
| |/
|/|
| |
| | |
Also call it `public_server.index_name` so it'll make more sense.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running tests, the Rails test runner would report the start of the test method as the test failure.
For this test:
```ruby
1 require 'test_helper
2
3 class BunnyTest < ActiveSupport::TestCase
4 test "something failing" do
5 assert false, 'This failed'
6 end
7 end
```
The runner outputs 5 instead of 4:
```
............................................F
This failed
bin/rails test test/models/bunny_test.rb:5
........
```
|
| |
| |
| |
| | |
The overall syntax of the file path is more important, not the exact line it was on.
|
| | |
|
| | |
|