| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
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`)
|
|
|
|
| |
This reverts commit 9a80f52541ed2c93ebef02909ecab3aaf9127150.
|
|
|
|
|
|
| |
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
```
|
|\ \
| | |
| | | |
Drop the before_fork/on_worker_boot advice
|
| | |
| | |
| | |
| | |
| | | |
It's no longer required for Active Record, and other common libraries
(dalli, redis-rb) all seem to be fork-proof too.
|
| | | |
|
| | |
| | |
| | |
| | | |
Fixes #31286
|
| | |
| | |
| | |
| | | |
Fixes #31282.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The `keyfile` was renamed to `credentials` in `google-cloud-storage` 1.8.0.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/master/google-cloud-storage/CHANGELOG.md#180--2017-11-14
Although `keyfile` can still be used, but it looks like deprecate.
https://github.com/GoogleCloudPlatform/google-cloud-ruby/blob/ddf7b2a856d676316525eb581c1a4cc83ca6097b/google-cloud-storage/lib/google/cloud/storage.rb#L589...L590
Therefore, I think that should use `credentials` in newly generated
applications.
Ref: https://github.com/GoogleCloudPlatform/google-cloud-ruby/issues/1802
|
| | |
|
| |
| |
| |
| | |
Follow up of 924a368f5c654f5304e575c767eb0fc64adc8659
|
| | |
|
| |
| |
| |
| |
| | |
This will keep the behavior of an application with the defaults of a 4.2
or 5.0 application behaving the same when upgrading to 5.2.
|
|/
|
|
|
|
| |
Since `ContentSecurityPolicy::Middleware` is not loaded in API-only
Applications, initializer is unnecessary.
Ref: https://github.com/rails/rails/blob/9c10fec4c06da38f8975dfb851f4d899aa85f8b7/railties/lib/rails/application/default_middleware_stack.rb#L66..L68
|
|
|
|
| |
- Followup of #31162
|
|
|
|
| |
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
|
|
|
|
|
|
|
| |
In order to use early hints, need to use Puma 3.11.0 or higher.
So, I think that should specify that version in newly generated applications.
Ref: https://github.com/puma/puma/commit/f6f3892f4d82638fb7a2a57d993641b1486ee88a
|
|\
| |
| | |
Clean database naming ambiguity
|
| |
| |
| |
| | |
In some places this file referred to the database in three different ways: database, DB and db. The last one caused confusion with the db namespace and the db folder. This commit removes this ambiguity by using the whole word 'database' everywhere
|
|/
|
|
|
|
| |
This was added with 27f103fc7e3260efe0b8dde66bf5354f2202ee32 for link labels and fields.
However, `form_with` changed to generates ids by default with d3893ec38ec61282c2598b01a298124356d6b35a.
So I think that adding an explicit ids is unnecessary.
|
|
|
|
|
| |
When load `5.1` config, `form_with_generates_remote_forms` is set.
https://github.com/rails/rails/blob/89a209f1abba5a2320d31c4898dea150c0abd0c0/railties/lib/rails/application/configuration.rb#L86
|
|
|
|
|
| |
Own style guide says we should be using parentheses for method calls
with arguments.
|
|
|
|
|
| |
When the defaults being loaded are the 5.0 or 5.1 we disable generation
of ids with form_with.
|
|
|
|
|
|
|
|
|
|
| |
When `form_with` was introduced we disabled the automatic
generation of ids that was enabled in `form_for`. This usually
is not an good idea since labels don't work when the input
doesn't have an id and it made harder to test with Capybara.
You can still disable the automatic generation of ids setting
`config.action_view.form_with_generates_ids` to `false.`
|
| |
|
|
|
|
| |
include :en
|
| |
|
|
|
|
|
|
|
|
|
| |
Since fbd1e98cf983572ca9884f17f933ffe92833632a, Rails plugin does not
run `bundle install` when generating.
Therefore, `after_bundle` callback is not actually executed after `bundle`.
Since there is a difference between the name and the actual behavior,
I think that should be remove.
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
| |
We generate master key on `rails new`.
Therefore, if do not add master key to `.gitginore` on `rails new`as
well, there is a possibility that the master key will be committed
accidentally.
|
| |
|
|\
| |
| |
| | |
Fixes https://github.com/rails/rails/pull/30940
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
To edit/show encrypted file:
```
bin/rails encrypted:edit config/staging_tokens.yml.enc
bin/rails encrypted:edit config/staging_tokens.yml.enc --key config/staging.key
bin/rails encrypted:show config/staging_tokens.yml.enc
```
Also provides a backing Rails.application.encrypted API for Ruby access:
```ruby
Rails.application.encrypted("config/staging_tokens.yml.enc").read
Rails.application.encrypted("config/staging_tokens.yml.enc").config
Rails.application.encrypted("config/staging_tokens.yml.enc", key: "config/staging.key")
```
|
| |
| |
| |
| | |
Instead of stashing the values in constants.
|
|\ \
| | |
| | | |
Update plugin_generator.rb
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Ensure plugin_generator adds to new line in Gemfile, even if the Gemfile
does not end with an empty line.
[Lisa Ugray, Nikita Penzin]
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently the environment is not loaded in some db tasks.
Therefore, if use encrypted secrets values in `database.yml`,
`read_encrypted_secrets` will not be true, so the value can not be
used correctly.
To fix this, added `environment` as dependency of `load_config`.
It also removes explicit `environment` dependencies that are no longer
needed.
Fixes #30717
|
| |
| |
| |
| |
| |
| |
| |
| | |
Make clear that the files are not to be run for interpreters.
Fixes #23847.
Fixes #30690.
Closes #23878.
|
|\ \
| | |
| | | |
Make automatically synchronize test schema work inside engine
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Rails engine, migration files are in under `db/migrate` of engine.
Therefore, when rake task is executed in engine, `db/migrate` is
automatically added to `DatabaseTasks.migrations_paths`.
https://github.com/rails/rails/blob/a18cf23a9cbcbeed61e8049442640c7153e0a8fb/activerecord/lib/active_record/railtie.rb#L39..L43
However, if execute the rake task under dummy app, migration files will not
be loaded because engine's migration path setting process is not called.
Therefore, in order to load migration files correctly, it is necessary to
execute rake task under engine.
Fixes #30765
|
| | |
| | |
| | |
| | |
| | | |
It's already a default for new apps, like so many others, so
no need to flaunt it.
|