When set, validates that the timestamp prefix for a migration is in the form YYYYMMDDHHMMSS.
This is designed to prevent migration timestamps from being modified by hand.
It is turned off by default.
These tests have never run in CI due to CI using a root user. This
commit keeps that behavior without using the skip so that we can enable
raise on skips.
When generating a new app, `bundle install` may be run multiple times
due to various application templates. This can create a lot of noise
in the output log, particularly with Bundler <= 2.4.16, which displays
the full list of gems each time `bundle install` is run.
To reduce noise, this commit adds the `--quiet` flag to `bundle install`
commands.
__Before__
```console
$ rails new my_cool_app --dev
create
create Gemfile
run bundle install
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/..........
Bundle complete! 1 Gemfile dependency, 58 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
run rails new my_cool_app --dev
exist
remove Gemfile
remove Gemfile.lock
create README.md
...
run bundle install
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Bundle complete! 12 Gemfile dependencies, 78 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
...
rails importmap:install
apply importmap-rails-1.2.3/lib/install/install.rb
...
run bundle install
Bundle complete! 12 Gemfile dependencies, 78 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
rails turbo:install stimulus:install
apply turbo-rails-1.5.0/lib/install/turbo_with_importmap.rb
...
run bundle install
Bundle complete! 12 Gemfile dependencies, 78 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
apply turbo-rails-1.5.0/lib/install/turbo_needs_redis.rb
Enable redis in bundle
gsub Gemfile
run bundle install
Fetching gem metadata from https://rubygems.org/..........
Resolving dependencies...
Bundle complete! 13 Gemfile dependencies, 80 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
Switch development cable to use redis
gsub config/cable.yml
run bundle install
Bundle complete! 13 Gemfile dependencies, 80 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
apply stimulus-rails-1.3.0/lib/install/stimulus_with_importmap.rb
...
run bundle install
Bundle complete! 13 Gemfile dependencies, 80 gems now installed.
Use `bundle info [gemname]` to see where a bundled gem is installed.
```
__After__
```console
$ rails new my_cool_app --dev
create
create Gemfile
run bundle install --quiet
run rails new my_cool_app --dev
exist
remove Gemfile
remove Gemfile.lock
create README.md
...
run bundle install --quiet
...
rails importmap:install
apply importmap-rails-1.2.3/lib/install/install.rb
...
run bundle install --quiet
rails turbo:install stimulus:install
apply turbo-rails-1.5.0/lib/install/turbo_with_importmap.rb
...
run bundle install --quiet
apply turbo-rails-1.5.0/lib/install/turbo_needs_redis.rb
Enable redis in bundle
gsub Gemfile
run bundle install --quiet
Switch development cable to use redis
gsub config/cable.yml
run bundle install --quiet
apply stimulus-rails-1.3.0/lib/install/stimulus_with_importmap.rb
...
run bundle install --quiet
```
Note that `bundle install` still displays any errors when using the
`--quiet` flag:
```console
$ bundle install
Could not find gem 'rails (= 9001.0)' in rubygems repository https://rubygems.org/ or installed locally.
The source contains the following gems matching 'rails':
* rails-0.8.0
...
* rails-7.1.2
```
When running `bundle install` for the `bin/rails app:template` command,
it is unnecessary and possibly even incorrect to also run
`bundle lock --add-platform=...` (because it could add a platform that
the user has intentionally removed). Likewise, when running
`bundle install` to support a prerelease version of Rails, it is
unnecessary to run `bundle lock --add-platform=...`.
This commit extracts `bundle lock --add-platform=...` from `run_bundle`
into its own `add_bundler_platforms` generator task.
Follow-up to #47516 / #47492.
When running generator tests on `arm64` platforms, there is an extra
`lock --add-platform` command in `@bundle_commands` which causes
`assert_match %r"^exec rails ...", @bundle_commands[2]` to fail.
However, `run_generator_using_prerelease` isn't really concerned with
`lock --add-platform` commands; it is only concerned with the `install`
and `exec rails` commands, and the contents of the `Gemfile` when those
commands were executed.
Therefore, this commit removes `lock --add-platform` command-related
assertions from `run_generator_using_prerelease` and puts them into a
dedicated `test_generation_runs_bundle_lock_for_linux` test. This
approach makes `run_generator_using_prerelease` less brittle. This
change also fixes a technically incorrect assertion wherein the contents
of the `Gemfile` during the `lock --add-platform` command was checked
instead of the contents during the `exec rails` command.
Fixes#50168.
Co-authored-by: zzak <zzakscott@gmail.com>
It's a common useful pattern for situation where something isn't
supposed to happen, but if it does we can recover from it.
So in such situation you don't want such issue to be hidden
in development or test, as it's likely a bug, but do not want to
fail a request if it happens in production.
In other words, it behaves like `#record` in development and test
environments, and like `raise` in production.
Fix: https://github.com/rails/rails/pull/49638
Fix: https://github.com/rails/rails/pull/49339
Co-Authored-By: Andrew Novoselac <andrew.novoselac@shopify.com>
Co-Authored-By: Dustin Brown <dbrown9@gmail.com>
Right now adapters have to expose a rather byzantine API:
- They must be defined in `active_record/connection_adapters/<name>_adapter`
- They must define `ConnectionHandling.<name>_adapter_class`
- They must define `ConnectionHandling.<name>_connection`
All this is not very DRY and a bit annoying. Additionally it makes
it very hard to define aliases (e.g. `mysql` => `trilogy`), or to
substitute a default adapter for a specialized one.
This refactor aims at making all this easier by exposing a simple
`register` method, that third party adapters can call from a Railtie.
The db:system:change command was [updated][1] to include support for
changing the database packages installed in the Dockerfile. However, it
never checks that the Dockerfile exists before trying to perform a
substitution and will raise an error when its missing:
```
/home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/actions/file_manipulation.rb:272:in `binread': No such file or directory @ rb_sysopen - /home/hartley/test/dev_minimal/Dockerfile (Errno::ENOENT)
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/actions/file_manipulation.rb:272:in `gsub_file'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/generators/rails/db/system/change/change_generator.rb:47:in `edit_dockerfile'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `block in invoke_all'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `each'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `map'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:134:in `invoke_all'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/group.rb:232:in `dispatch'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/base.rb:584:in `start'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/commands/db/system/change/change_command.rb:20:in `perform'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/command.rb:28:in `run'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor/invocation.rb:127:in `invoke_command'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command/base.rb:178:in `invoke_command'
from /home/hartley/.cache/asdf/installs/ruby/3.2.2/lib/ruby/gems/3.2.0/gems/thor-1.3.0/lib/thor.rb:527:in `dispatch'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command/base.rb:73:in `perform'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:71:in `block in invoke'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:149:in `with_argv'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/command.rb:69:in `invoke'
from /home/hartley/src/github.com/skipkayhil/rails/railties/lib/rails/commands.rb:18:in `<top (required)>'
from bin/rails:4:in `require'
from bin/rails:4:in `<main>'
```
This commit fixes the issue by checking first whether the Dockerfile
exists before trying to perform any substitution on it.
[1]: ac9f08d1c354baab6362d7050a3c9e43db09689c
By default, calling `inspect` on a record will yield a formatted string including just the `id`.
```ruby
Post.first.inspect #=> "#<Post id: 1>"
```
The attributes to be included in the output of `inspect` can be configured with
`ActiveRecord::Core#attributes_for_inspect`.
```ruby
Post.attributes_for_inspect = [:id, :title]
Post.first.inspect #=> "#<Post id: 1, title: "Hello, World!">"
```
With the `attributes_for_inspect` set to `:all`, `inspect` will list all the record's attributes.
```ruby
Post.attributes_for_inspect = :all
Post.first.inspect #=> "#<Post id: 1, title: "Hello, World!", published_at: "2023-10-23 14:28:11 +0000">"
```
In e28f147329330e7ae55606e62ecc3de328431f0b the `show_exceptions`
default was updated to `:rescuable` in environments/test.rb.
The description still described the old default value (`false`), instead
of `:rescuable`.
This commit separates inline attachments from normal attachments when
listing attachments in Action Mailer previews. For example, attachments
that were previously listed like
> Attachments: logo.png file1.pdf file2.pdf
will now be listed like
> Attachments: file1.pdf file2.pdf (Inline: logo.png)
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
There was many public reports of 15-25% latency improvements for Rails
apps that did enable Ruby 3.2 YJIT, and in 3.3 it's even better.
Following https://github.com/ruby/ruby/pull/8705, in Ruby 3.3 YJIT
is paused instead of disabled by default, allowing us to enable it
from an initializer.
Remove the option `config.public_file_server.enabled` from the generators for all environments, as the value is the same in all environments.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
* "Ignoring db/schema_cache.yml because it has expired."
Before:
```
bin/test test/application/rake/multi_dbs_test.rb -n "schema_cache is loaded on primary db in multi-db app"
Run options: -n "schema_cache is loaded on primary db in multi-db app" --seed 13139
Ignoring db/schema_cache.yml because it has expired. The current schema version is 20231017102756, but the one in the schema cache file is 20231017102755.
.
```
Added test cases for this error and "Failed to validate schema cache" in `test/application/rake/dbs_test.rb`.
Follow-up to #47137.
Since `config.public_file_server.enabled` is true by default, this
commit changes the `config/environments/production.rb` template to
present the setting as an opt-out.
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.
