| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | | |
app:update` in app_generator_test.rb
|
| | | |
| | | |
| | | |
| | | |
| | | | |
The mock is called three times because the `spring_install?` call has
been added in 65344f254cde87950c7f176cb7aa09c002a6f882.
|
| | | | |
|
| | | |
| | | |
| | | | |
It's unusable and not ready to ship in Rails 6.0. We'll rewrite it for 6.1.
|
|/ / /
| | |
| | |
| | | |
See rationale in the warning message included in the patch.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The original message from Zeitwerk is "can't reload, please call
loader.enable_reloading before setup (Zeitwerk::Error)", which is not
very informative for Rails programmers.
Rails should err with a message worded in terms of its interface.
|
|/ /
| |
| |
| |
| | |
It is necessary to run `rubocop` manually when new cop is added since
codeclimate checks any offences only in files touched in PRs.
|
|\ \
| | |
| | | |
Only override async adapter when seeding
|
| | | |
|
| | | |
|
|/ / |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
We have `Style/RedundantBegin` cop (#34764) but it could not correct in
this case.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
regression for fixture loading
d8d6bd5 makes fixture loading to bulk statements by using
`execute_batch` for sqlite3 adapter. But `execute_batch` is slower and
it caused the performance regression for fixture loading.
In sqlite3 1.4.0, it have new batch method `execute_batch2`. I've
confirmed `execute_batch2` is extremely faster than `execute_batch`.
So I think it is worth to upgrade sqlite3 to 1.4.0 to use that method.
Before:
```
% ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids
Using sqlite3
Run options: -n test_eager_loading_too_may_ids --seed 35790
# Running:
.
Finished in 202.437406s, 0.0049 runs/s, 0.0049 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 142.57s user 60.83s system 98% cpu 3:27.08 total
```
After:
```
% ARCONN=sqlite3 bundle exec ruby -w -Itest test/cases/associations/eager_test.rb -n test_eager_loading_too_may_ids
Using sqlite3
Run options: -n test_eager_loading_too_may_ids --seed 16649
# Running:
.
Finished in 8.471032s, 0.1180 runs/s, 0.1180 assertions/s.
1 runs, 1 assertions, 0 failures, 0 errors, 0 skips
ARCONN=sqlite3 bundle exec ruby -w -Itest -n test_eager_loading_too_may_ids 10.71s user 1.36s system 95% cpu 12.672 total
```
|
| |
| |
| |
| |
| | |
* The fix is already in master since https://github.com/rails/rails/pull/34243
* See https://github.com/rails/rails/pull/35482 for the fix in Rails 5.2
|
| | |
|
|\ \
| | |
| | | |
Add attachment and attachments field generators
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add db:prepare rake task.
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
We introduced `connection` option for specifying spec with 1acd9a6464668d4d54ab30d016829f60b70dbbeb.
But now we are using the `database` to specify the same value in other commands.
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/migration/migration_generator.rb#L11
* https://github.com/rails/rails/blob/0a0f115031b64b5335fa88543c40df4194dfb428/activerecord/lib/rails/generators/active_record/model/model_generator.rb#L17
The options provided to the users should be uniform. Since the term
"database" is used in rake task etc, So I want to be able to use it in
`dbconsole` command.
Also I deprecated the `connection` option because I think that it
would be confusing if there are multiple options to specify a same value.
|
|\ \ \ \
| | | | |
| | | | | |
url -> URL where apt except inside actionpack/
|
| | | | | |
|
|/ / / / |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
During initialization, the eager load paths of engines are unshifted
into AS::Dependencies.autoload_paths. After that, the collection is
frozen. (See the initializers in railties/lib/rails/engine.rb.)
Hence, there is no eager load path that is not an autoload path too, and
so the array difference in the deleted code is always an empty array.
Just do nothing.
|
| |/ /
|/| | |
|
|/ / |
|
| | |
|
|\ \
| | |
| | | |
Replace chromedriver-helper with webdrivers
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Add config.disable_sandbox option to Rails console
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
A long-running `rails console --sandbox` could cause a database server
to become out-of-memory as it's holding on to changes that happen on the
database.
Given that it's common for Ruby on Rails application with huge
traffic to have separate write database and read database, we should
allow the developers to disable this sandbox option to prevent someone
from accidentally causing the Denial-of-Service on their server.
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
Since `secret_key_base` is expected to be included in credential file,
`secret_key_base` should be included even if re-create the file. This is
the same behavior as creating a new app.
When env is specified, it may be unnecessary, so I added it only when not
specifying env.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since https://github.com/puma/puma/pull/1700, the default host is
correctly used. So `localhost` is used instead of `0.0.0.0`.
As a result, the log output on restart is changed, and the restart test
fails on Puma 3.12.1.
https://travis-ci.org/rails/rails/jobs/509239592#L2303-L2305
Specify binding explicitly to avoid being affected by Puma changes.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thor automatically adds `-` if aliases do not start with `-`.
https://github.com/erikhuda/thor/blob/0879c1773d188902d54f95174f33961ac33111f8/lib/thor/parser/options.rb#L53
But Thor follows a convention of one-dash-one-letter options.
So, even if `-` is added to `db`, it does not work.
https://github.com/erikhuda/thor/blob/0879c1773d188902d54f95174f33961ac33111f8/lib/thor/parser/options.rb#L4
Follow up #34021.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is kind of hard to explain but if you have a database config with
another level like this:
```
development:
primary:
database: "my db"
variables:
statement_timeout: 1000
```
the database configurations code would chooke on the `variables` level
because it didn't know what to do with it.
We'd see the following error:
```
lib/active_record/database_configurations.rb:72:in
`block in find_db_config': undefined method `env_name' for [nil]:Array
(NoMethodError)
```
The problem here is that Rails does correctly identify this as not a
real configuration but returns `[nil]` along with the others. We need to
make sure to flatten the array and remove all the `nil`'s before
returning the `configurations` objects.
Fixes #35646
|
| |
| |
| |
| | |
This allows specifying the environment as would any other rails commands.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 3777701f1380f3814bd5313b225586dec64d4104, the environment's name is
automatically expanded in console and dbconsole commands.
In order to match the behavior between the commands, fixes it to have the
same behavior of all the commands.
This behavior is defined in `EnvironmentArgument`. Since
`EnvironmentArgument` also defines the environment option, it is reused.
However, since desc was not content that can be used in all comments,
fixed desc to be defined for each command.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The tmp directory is added to version control in the newly created
application. This was added in Rails 5.0.0(https://github.com/rails/rails/commit/f06ce4c12a396795a3b2c1812951d9277bcb3a82).
However, applications created before that are not guaranteed to have the
tmp directory. If the tmp directory does not exist, writing to the key file
raise error.
This is a bit incompatible. So I fixed that create the directory before
writing a key.
|
| |
| |
| |
| |
| |
| | |
This was missed in the security fix for local dev. CI doesn't have a tmp
directory in the apps built for testing so these end up failing. This
adds the secret_key_base so we don't need to generate one.
|
|\ \
| | |
| | |
| | | |
v6.0.0.beta3 release
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If the secret_key_base is nil in dev or test generate a key from random
bytes and store it in a tmp file. This prevents the app developers from
having to share / checkin the secret key for dev / test but also
maintains a key between app restarts in dev/test.
[CVE-2019-5420]
Co-Authored-By: eileencodes <eileencodes@gmail.com>
Co-Authored-By: John Hawthorn <john@hawthorn.email>
|
| | | |
|
| | |
| | |
| | |
| | | |
This adds a few additional tests to the commits by eileencodes (https://github.com/rails/rails/pull/35497) and rafaelfranca (https://github.com/rails/rails/commit/cfa22f1a4b5e8b95ee01a432168de2f831b3f788). The additional tests cover several more ERB tag formatting cases such as multiline tags, conditional statements that result in duplicate keys, and multiple erb statements on a single line.
|
| | | |
|