| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
- Add set_locale to detect suitable locale
- Make feature compatible with Rails 5.x
|
|
|
|
|
|
|
|
|
|
|
|
| |
down is only called with a block from the rake tasks where it passes a
`SCOPE`. Technically this was tested but since we don't run all the
migrations we're not actually testing the down works with a `SCOPE`. To
ensure we're testing both we can run `db:migrate` again to migrate users
and then run `down` with a scope to test that only the bukkits migration
is reverted.
Updates test to prevent having to fix regressions like we did in
4d4db4c.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rails has some support for multiple databases but it can be hard to
handle migrations with those. The easiest way to implement multiple
databases is to contain migrations into their own folder ("db/migrate"
for the primary db and "db/seconddb_migrate" for the second db). Without
this you would need to write code that allowed you to switch connections
in migrations. I can tell you from experience that is not a fun way to
implement multiple databases.
This refactoring is a pre-requisite for implementing other features
related to parallel testing and improved handling for multiple
databases.
The refactoring here moves the class methods from the `Migrator` class
into it's own new class `MigrationContext`. The goal was to move the
`migrations_paths` method off of the `Migrator` class and onto the
connection. This allows users to do the following in their
`database.yml`:
```
development:
adapter: mysql2
username: root
password:
development_seconddb:
adapter: mysql2
username: root
password:
migrations_paths: "db/second_db_migrate"
```
Migrations for the `seconddb` can now be store in the
`db/second_db_migrate` directory. Migrations for the primary database
are stored in `db/migrate`".
The refactoring here drastically reduces the internal API for migrations
since we don't need to pass `migrations_paths` around to every single
method. Additionally this change does not require any Rails applications
to make changes unless they want to use the new public API. All of the
class methods from the `Migrator` class were `nodoc`'d except for the
`migrations_paths` and `migrations_path` getter/setters respectively.
|
|\
| |
| | |
Use SHA-1 for non-sensitive digests by default
|
| |
| |
| |
| |
| |
| | |
Instead of providing a configuration option to set the hash function,
switch to SHA-1 for new apps and allow upgrading apps to opt in later
via `new_framework_defaults_5_2.rb`.
|
|\ \
| | |
| | |
| | | |
PostgreSQL: Allow pg-1.0 gem to be used with ActiveRecord
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
pg-1.0.0 is just released and most Gemfiles don't restrict
it's version. But the version is checked when connecting to
the database, which leads to the following error:
Gem::LoadError: can't activate pg (~> 0.18), already activated pg-1.0.0
See also this pg issue:
https://bitbucket.org/ged/ruby-pg/issues/270/pg-100-x64-mingw32-rails-server-not-start
Preparation for pg-1.0 was done in commit f28a331023fab,
but the pg version constraint was not yet relaxed.
|
|\ \ \
| |/ /
|/| | |
Add support for Minitest 5.11
|
| | |
| | |
| | |
| | | |
Ref: http://docs.seattlerb.org/minitest/Minitest/Result.html#attribute-i-klass
|
| | |
| | |
| | |
| | |
| | | |
`filtered_results` returns an instance of `Minitest::Result` since https://github.com/seattlerb/minitest/commit/00433fc0a4fdd0e6b302aace633384ba13122376
`Minitest::Result` is not test class. So cannot get location directly.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Remove `AppGeneratorTest#test_active_storage_install`.
The test is added by 67db41aa7f17c2d34eb5a914ac7a6b2574930ff4,
since #31534 this test doesn't test anything.
Remove redundant assertions in `SharedGeneratorTests`.
These assertions is added by 4a835aa3236eedb135ccf8b59ed3c03e040b8b01.
Follows 67db41aa7f17c2d34eb5a914ac7a6b2574930ff4, #31534.
|
|\ \ \
| |_|/
|/| | |
Don't include Active Storage migrations in new apps
|
| | |
| | |
| | |
| | | |
See #31315 for full discussion
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
new_framework_defaults_5_2.rb
Enabling this option in new_framework_defaults_5_2.rb didn't work
before, as railtie initializers run before application initializers.
Using `respond_to?` to decide whether to set the option wasn't working
either, as `ActiveSupport::OrderedOptions` responds to any message.
|
| |/
|/|
| |
| | |
start the Rails server
|
| |
| |
| |
| |
| | |
* `assert_header` and `assert_body` were unused since 6f6a589.
* `assert_success` and `assert_missing` were unused since added.
|
| |
| |
| |
| |
| |
| | |
`invoke_all` cause `bundle install`. This will install gems actually
defined in `Gemfile`. To avoid this, stubbed `bundle_command`.
Fixes #31557
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Puma gets bundler's info from `Bundler::ORIGINAL_ENV` for restart.
https://github.com/puma/puma/blob/f6f3892f4d82638fb7a2a57d993641b1486ee88a/lib/puma/launcher.rb#L168
So, specified `BUNDLE_GEMFILE` env for use same Gemfile in the restart.
Fixes #31351
|
| |
| |
| |
| | |
`skip_bundle` option was removed from plugin generator in 9b72fcc3c22a6f75f37f52dd6cb682bc00c51cf0.
|
|\ \
| | |
| | | |
Handle `FrozenError` if it is available
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This pull request handles `FrozenError` introduced by Ruby 2.5.
Refer https://bugs.ruby-lang.org/projects/ruby-trunk/repository/revisions/61131
Since `FrozenError` is a subclass of `RuntimeError` minitest used by master
branch can handle it, though it would be better to handle `FrozenError`
explicitly if possible.
`FrozenError` does not exist in Ruby 2.4 or lower, `frozen_error_class`
handles which exception is expected to be raised.
This pull request is intended to be merged to master,
then backported to `5-1-stable` to address #31508
|
| | |
| | |
| | |
| | | |
Follow up of #31289.
|
|/ /
| |
| |
| |
| |
| |
| | |
Specifying the `--dev` option is when want to change the codebase,
as it is not necessary to cache it.
Context: https://github.com/rails/rails/pull/31485#issuecomment-352452653
|
|\ \
| | |
| | | |
Raise an error only when `require_master_key` is specified
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
To prevent errors from being raise in environments where credentials
is unnecessary.
Context: https://github.com/rails/rails/issues/31283#issuecomment-348801489
Fixes #31283
|
|\ \ \
| |/ /
|/| | |
Add `skip_bootsnap` option
|
| |/
| |
| |
| |
| |
| | |
`bootsnap` is a useful gem normally. However, `bootsnap` is unnecessary
when generating a Rails application to be used only for testing.
So I want to control whether use this or not by option.
|
|/
|
|
| |
Follow up of #31391
|
|\
| |
| | |
Log the original call site for an ActiveRecord query
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This new ActiveRecord configuration option allows you to easily
pinpoint what line of application code is triggering SQL queries in the
development log by appending below each SQL statement log the line of
Ruby code that triggered it.
It’s useful with N+1 issues, and to locate stray queries.
By default this new option ignores Rails and Ruby code in order to
surface only callers from your application Ruby code or your gems.
It is enabled on newly generated Rails 5.2 applications and can be
enabled on existing Rails applications:
```ruby
Rails.application.configure do
# ...
config.active_record.verbose_query_logs = true
end
```
The `rails app:upgrade` task will also add it to
`config/development.rb`.
This feature purposely avoids coupling with
ActiveSupport::BacktraceCleaner since ActiveRecord can be used without
ActiveRecord. This decision can be reverted in the future to allow more
configurable backtraces (the exclusion of gem callers for example).
|
|/
|
|
| |
Follow up of #31432.
|
| |
|
|
|
|
| |
Follow up of #31390.
|
|
|
|
|
|
|
|
|
| |
Option parsing happens too late to have any impact on the Rails
environment. Rails accesses the environment name and memoizes it too
early in the boot process for a commandline option to have any impact on
the database connection, so we'll change this test to set the
environment from an environment variable (and ensure it still works when
running tests with `ruby`)
|
|
|
|
|
|
| |
When tests are run with just `ruby`, the RAILS_ENV is set to
`development` too early, and we connect to the development database
rather than the test database.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I frequently run tests with `ruby`, not with a runner like `rake` or
`rails`. When running the test with just `ruby` the `RAILS_ENV`
environment variable did not get set to "test", and this would cause the
tests to fail (and even mutate the development database!)
This commit adds integration tests for running tests with just `ruby`
and ensures the environment gets defaulted to "test". I also added a
test to ensure that passing an environment to `-e` actually works (and
fixed that case too).
An interesting / annoying thing is that Minitest picks up it's plugins
by asking RubyGems for a list of files:
https://github.com/seattlerb/minitest/blob/ca6a71ca901016db09a5ad466b4adea4b52a504a/lib/minitest.rb#L92-L100
This means that RubyGems needs to somehow know about the file before it
can return it to Minitest. Since we are not packaging Rails as a Gem
before running the integration tests on it (duh, why would you do
that?), RubyGems doesn't know about the file, so it can't tell Minitest,
so Minitest doesn't automatically require it. This means I had to
manually require and insert the plugin in our integration test. I've
left comments about that in the test as well.
Ugh.
|
| |
|
| |
|
|\
| |
| | |
Add tests for the `--webpack` option
|
| |
| |
| |
| |
| | |
We probably don't have any tests for the `--webpack` option.
related: #27288
|
|\ \
| | |
| | |
| | |
| | | |
y-yagi/ignore_no_database_error_when_loading_schema_cache
Ignore `NoDatabaseError` when loading schema cache
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is necessary in order to make the processing dependent on
`Migrator.current_version` work even without database.
Context: https://github.com/rails/rails/pull/31135#issuecomment-348404326
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
With the current code, a failing test shows this error, which is missing
the number of times called and has two periods at the end.
```
/railties$ be ruby -Itest test/generators/app_generator_test.rb -n test_active_storage_install
Failure:
AppGeneratorTest#test_active_storage_install [test/generators/app_generator_test.rb:313]:
active_storage:install expected to be called once, but was called times..
Expected: 1
Actual: 2
```
After the fix, the error message looks correct:
```
/railties$ be ruby -Itest test/generators/app_generator_test.rb -n test_active_storage_install
Failure:
AppGeneratorTest#test_active_storage_install [test/generators/app_generator_test.rb:313]:
active_storage:install expected to be called once, but was called 2 times.
Expected: 1
Actual: 2
```
|
|/
|
|
| |
Fixes #31286
|
|
|
|
| |
Follow up of 924a368f5c654f5304e575c767eb0fc64adc8659
|