Using `config.secret_key_base` currently raises a deprecation warning
when used in production because `config.secret_key_base` gets merged
into the `secrets` hash instead of being looked up specifically in
the `secret_key_base` method.
This commit addresses this by not raising a deprecation warning if
`secrets.secret_key_base` and `config.secret_key_base` are the same
object (meaning `config.secret_key_base` was merged into `secrets).
Additionally, an improved deprecation warning is added for apps that
continue to set `secret_key_base` in their secrets. The current warning
is not great because it isn't directly actionable for users. Currently
they will see the warning, not see `secrets` being referenced in their
app, and potentially end up confused. The new warning helps users
understand the actual change they need to make: not removing a reference
to `secrets` but moving `secret_key_base` out of `secrets`.
For better or worse, the Rails guide settled on double quotes
and a large part of the community also use rubocop which enforce
them by default.
So we might as well try to follow that style when providing code
snippets in the documentation or error messages.
Fix: https://github.com/rails/rails/issues/49822
I certainly didn't get them all, but consistency should be significantly
improved.
The warning string is `#squish`ed however `core_ext/string/filters` was
not being required. The tests were passing because the dummy test
application does a `require 'rails/all'` on boot. This is not necessarily
the case for other applications, eg ones freshly created with `rails new`.
Follow-up to #45734.
This re-adds support for using `enum` with non-column-backed attributes
while still guarding against typos in enum attribute names. When using
`enum` with a non-column-backed attribute, the attribute must be
previously declared with an explicit type. For example:
```ruby
class Post < ActiveRecord::Base
attribute :topic, :string
enum topic: %i[science tech engineering math]
end
```
Fixes#49717.
In `bootstrap.rb` we set the `Rails.logger.level` to `config.log_level`. But at this point, we may have already set up a `BroadcastLogger` with multiple broadcasts that have different levels. So, calling `level=` on the `BroadcastLogger` will overwrite the level of the individual broadcasts. So instead, let's only set the `Rails.logger.level` if the logger is not a `BroadcastLogger`.
A new condition was recently [added][1] to exclude error_highlight from
the Gemfile when the Ruby version is 3.2 or greater. However, this
change leads to an extra blank line after `gem "spring"` on Ruby 3.2+.
This could also happen to new apps generated on Rubies < 3.1, but my
guess is that is less common.
This commit fixes the issue by moving the extra blank line into the
condition.
[1]: d7b395145c644434b1c2be07ef334ea5cb643b75
In 11a6adc4fb6172e9af081e20c5f68ca023e3bd8a custom code was added to
restrict values for some `rails new` options.
We don't need to implement this when it's already supported by Thor.
This also adds `none` as an option to the asset_pipeline as used in:
`railties/test/generators/shared_generator_tests.rb:320`.
Add email to the list of default filter parameters
Email addresses are considered personal data. While not quite on the same level of sensitivity as the other parameters in the list any application that implements signup through email without SSO inadvertently logs this information.
The `--database`, `--asset-pipeline`, `--css`, and `--javascript` flags for
`rails new` can all take different options. However, only `--database` has
a check to make sure the correct option is given.
If someone where to fat-finger a value, for example `--javascript=esbuiild`,
they most likely would be left with either importmaps used or some other
undefined behavior.
This change adds similar checks as the `--database` flag for the other four
options to make sure the user enters the correct value.
Without additional formatting, these method docs render as a single
line. For example,
```ruby
# GET show
# GET edit
# PATCH/PUT update
# DELETE destroy
```
renders as
```html
<p>GET show GET edit PATCH/PUT update DELETE destroy</p>
```
The goal of this code since the beginning was only to check invalid
attributes, not missing tables.
We can assume that if the person didn't create the table yet but
they do use it, some other test would fail.
Fixes#49500.
Right now we are using both to test the Rails applications we generate
and to test Rails itself. Let's keep CI for the app and BUILDKITE to
the framework.
Since `load_schema` is private API, we don't want it to be explicitly
called by RSpec.
This feature can be used by RSpec by exposing it in
`rails/testing/maintain_test_schema` so they don't need to reimplement
the same thing.
Some protections like the one that checks if an enum is pointing to
a valid column in the table only works when the database schema is
loaded to the model.
Before this change, if schema cache wasn't present and the right
combinations of configurations were not set, developers would only see
this exception in production.
With this change, those errors would be caught on CI, as soon the
tests are loaded.
* Conditionally print `$stdout` when invoking `run_generator`
In an effort to improve the developer experience when debugging
generator tests, we add the ability to conditionally print `$stdout`
instead of capturing it.
This allows for calls to `binding.irb` and `puts` work as expected.
```sh
PRINT_STDOUT=true ./bin/test test/generators/actions_test.rb
```
* Update railties/CHANGELOG.md
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Rename environment variable
* Update generators guides.
* Update guides
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
- This commit avoids having `Rails.logger` be a two level nested
BroadcastLogger. Side note that Nesting BroadcastLogger works and is
supported by the implementation but we shouldn't do it in that
case as it's confusing for the user.
rails new --skip-aciton-cable now generates config/environments/development.rb
without Action Cable configurations.
Follows up PRs 22586 and 24169
Signed-off-by: Takuya Noguchi <takninnovationresearch@gmail.com>
- An oversight of #48615 is that it changes the `Rails.logger` to be
a broadcast logger after the app is booted. Anything referencing
`Rails.logger` during the boot process will get a simple logger and
ultimately resulting in logs not being broadcasted.
For example `ActionController::Base.logger.info("abc")` would
just output logs in the `development.log` file, not on STDOUT.
----
The only solution I could think of is to create a BroadcastLogger
earlier at boot, and add logger to that broadcast when needed (instead
of modiyfing the `Rails.logger` variable).
Ideally we should be able to checkout an Adapter instance without
triggering a connection to the server.
For some adapters like Trilogy that is the case today, but only if
you have a schema cache loaded, otherwise `check_version` will trigger
a query.
I think this check can be delayed to when we actually use the connection.
