| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Running railties generated app tests in development env can cause unintended
consequences. The environments are different and tests aren't meant to be
run in development mode.
The changes to the generator exposed this issue where the random test
order in the generated apps could cause problems when those tests are
run in development mode.
Particularly we saw failures in `railties/test/application/rake_test.rb`
generated apps that used the scaffold to create applications and then
run the migration and immediately run the tests. The error we saw was
`ActiveRecord::RecordNotFound: Couldn't find User with 'id'=980190962`
and seemed to only occur if the destroy test ran first. I'm not entirely
sure _why_ this causes that error to be thrown but I believe it is
related to the environments being different.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Rails 5.1 `ActionController::TestCase` will be moved out of Rails
into it's own gem. Please use `ActionDispatch::IntegrationTest` going
forward.
This changes the generators to use `ActionDispatch::IntegrationTest` and
the required URL setup (rather than symbols) for each of the controller
actions.
Updated fix to #22076.
|
| |/
| |
| |
| | |
We will wait until 5.1 to make a decision
|
| |
| |
| |
| | |
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.
|
| | |
|
|/ |
|
|
|
|
|
|
|
|
|
| |
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
|
|\ \
| | |
| | | |
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.
|
|/
|
|
|
| |
Web Console 3.0.0 is compatible with Rails 5, while the 2.x.x releases
aren't.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
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
|
| | |
|
| |
| |
| |
| | |
Related with e62ddac05b7d827ae870898d7cd9eaf76e0730aa
|
| |
| |
| |
| | |
Related with 668c006cf33a63ac3f8a8f064c772a339341e70c.
|
|/ |
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
| |
generator
In the app generator, regardless of the namespace, it is adapted to read the same `application_controller.rb`,
modified to api generator also be the same behavior.
ref 686966a1861e6761021d45f6795de753e8a62216, 06ac63b4c602e4b26cb3bfbf0dfd2bed8b00e786
|
|
|
|
| |
Forgot to do it in 748b2f9, when deprecating `serve_static_files`.
|
|
|
|
|
|
|
|
| |
As discussed in https://github.com/rails/rails/pull/19135#issuecomment-153385986.
Replaces `serve_static_files` to unify the static options under the `public_file_server` wing.
Deprecates `serve_static_files` accessors, but make them use the newer config internally.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`1_valid_people_have_last_names.rb` and
`20150823202140_create_users.rb` are valid migration file name.
But `1_valid_people_have_last_names.rb` is rendered as
`********** NO FILE **********` when `rake db:migrate:status`.
Fix to this bug, this commit includes
* define some API private methdos and a Constant
`match_to_migration_filename?`, `parse_migration_filename`, and
`MigrationFilenameRegexp`
* use these methods in `db:migrate:status` task
Example:
These files are in `db/migrate`
* 1_valid_people_have_last_names.rb
* 20150819202140_irreversible_migration.rb
* 20150823202140_add_admin_flag_to_users.rb
* 20150823202141_migration_tests.rb
* 2_we_need_reminders.rb
* 3_innocent_jointable.rb
we can migrate all of them.
Before
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 ********** NO FILE **********
up 002 ********** NO FILE **********
up 003 ********** NO FILE **********
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
After
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 Valid people have last names
up 002 We need reminders
up 003 Innocent jointable
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
|
| |
|
| |
|
|
|
|
|
|
| |
We are using the same version constraint in the database adapters so
when a new version of the adapter that doesn't work with the version of
rails is released we don't break new applications.
|
|\
| |
| | |
Allow rake:stats to account for rake tasks
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
If `SECRET_KEY_BASE` or other `secret` gets passed as other then string
we need to raise `ArgumentError` to know that it's a wrong argument.
Closes #22072
|
|\ \
| | |
| | |
| | | |
Explicitly exit with status "1" for create and drop failures
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* If the drop task fails for a reason other than the database not
existing, processing should end. This is indicated by a non-zero
exit status.
* Since the backtrace is already printed to screen, we forgo
printing it again by using an explicit call to `exit`.
* :warning: This modifies the behavior of the db:create task slightly in
that the stack trace is no longer printed by default. If the `--trace`
option is used, it will print the trace _after_ the error message.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* If the create task fails for a reason other than the database already
existing, processing should end. This is indicated by a non-zero exit
status.
* Since the backtrace is already printed to screen, we forgo printing it
again by using an explicit call to `exit`.
* :warning: This modifies the behavior of the db:create task slightly in
that the stack trace is no longer printed by default. If the `--trace`
option is used, it will print the trace _after_ the error message.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Previously the sqlite3 adapter could not "fail" on drop. Now an error
is raised when no file exists.
* Also updates purge to be resilient of drop failures. This is how purge
is expected to behave.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Running the db:create task when the database already exists isn't
really an error case. That is processing may proceed in this case
because the database exists as requested. So let's validate that
behavior with a test.
* Likewise, if the database doesn't exist when running the db:drop task
processing may continue as the requested condition is already met.
Thus a test.
|
| | | |
|