This will be eager loaded by the define_attribute_methods initializer
now that the schema cache can be automatically loaded for all
connection if the file is present on disk after #48716.
The .devcontainer folder includes everything needed to boot the app and do development in a remote container.
The container setup includes:
- A redis container for Kredis, ActionCable etc.
- A database (SQLite, Postgres, MySQL or MariaDB)
- A Headless chrome container for system tests
- Active Storage configured to use the local disk and with preview features working
If any of these options are skipped in the app setup they will not be included in the container configuration.
These files can be skipped using the `--no-devcontainer` option.
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
When working in a devcontainer, for system tests we need to manually set the host and port serving the application. Let's introduce a method for this, so we don't have to expose the implementation details of Capybara to the developer.
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
This reverts commit 6985c3bedf0d85c180d8b86a2fcd6b19e7251bd3, reversing
changes made to 3163bb735189eddd7c152a1e72bed7b4d052f7d4.
Reason: While we want to apply this change, it make bundle being more
strict about the ruby version. This is particularly problematic for
the devcontainer images that don't support defining which patch
version of ruby to install.
Right now, you can only say you want Ruby 3.2, which could mean
3.2.3 or 3.2.0. If for some reason the devcontainer image doesn't
match the patch version on `.ruby-version` it will fail to install.
We are planning to solve this problem by publishing our own
ruby images that allow defining the patch level, but until that
we can't apply this change.
Previously, new apps would have a Ruby version set in both the Gemfile
and the .ruby-version file. This duplication makes it more difficult to
quickly change an application's ruby version as users must remember to
update multiple files.
This commit updates the app generator's Gemfile to read the Ruby version
from the .ruby-version file. Since this feature was introduced in the
latest version of Bundler, it will only be enabled if a supported version
of Bundler is used.
Alternatively, another solution mentioned on the original PR adding
.ruby-version was that the .ruby-version file could be removed once
rvm/rbenv support reading the Ruby version from the Gemfile. This has a
downside that many other tools like chruby do not have plans to support
reading a Ruby version from the Gemfile, and so users of those tools
would have a worse experience if the .ruby-version file is removed.
Co-authored-by: Takumi Shotoku <sinsoku.listy@gmail.com>
- If an application has files named `*_test.rb` in the
"fixtures/files" folder, they were picked up to be loaded.
In most cases this would result in a LoadError as its likely
those files include code that can't be loaded.
Configure ActiveRecord::Encryption (ARE) on ActiveRecord::Base (AR)
loading, so that ARE configs are ready before AR models start using
`encrypts` to declare encrypted attributes.
This means that you can add ARE configurations in initializers, as long
as you don't trigger the loading of ActiveRecord::Base or your AR models
in prior initializers.
Prefer references to git's default configuration, rather than encouraging customized configurations.
`git config core.excludesFile` defaults to `${XDG_CONFIG_HOME:-~/.config}/git/ignore`. This updates the .gitignore template to suggest the default location for git's global gitignore rather than a customized location.
This changes TestParser to parse with prism instead of ripper if it
is available for the current version of Ruby. It's within the margin
for the speed, and its significantly less code that is easier to
read and should be easier to maintain.
Ref: https://github.com/rails/rails/pull/50793
Transactional fixtures are currently tightly coupled with the pool
active connection. It assumes calling `pool.connection` will memoize
the checked out connection and leverage that to start a transaction
on it and ensure all subsequent accesses will get the same connection.
To allow to remove checkout caching (or make it optional), we first
must decouple transactional fixtures to not rely on it.
The idea is to behave similarly, but store the connection in
the pool as a special "pinned" connection, and not as the regular
active connection.
This allows to always return the same pinned connection,
but without necessarily assigning it as the active connection.
Additionally, this pinning impact all threads and fibers, so
that all threads have a consistent view of the database state.
When set, an `ActiveRecord::InvalidMigrationTimestampError` will be raised if the timestamp
prefix for a migration is more than a day ahead of the timestamp associated with the current time.
This is done to prevent forward-dating of migration files, which can impact migration generation
and other migration commands.
It is turned off by default, but will be turned on for applications starting in Rails 7.2.
At the moment, Rails::Rack::Logger tags the logger (if it's
ActiveSupport::TaggedLogging) for the duration of the @app.call, but
only fires the request.action_dispatch event later, on body close. That
means anything logged in request.action_dispatch handlers won't have the
same tags as the rest of the request.
Fix this by deferring the popping of tags into
finish_request_instrumentation, in the same way that finishing the
instrumentation handle is deferred.
This is invoked by Minitest before invoking the test, allowing
to print the test name in advance.
This is useful to debug slow and stuck tests by turning on verbose
mode. This way the stuck test name is printed before the process
deadlock.
Otherwise you have to resort to dirty tricks to figure out which
test is not returning.
This is also how the default Minitest reporter works in verbose
mode.
Followup: https://github.com/rails/rails/pull/50923
Instead of stopping on the first frame that isn't in
Action Dispatch, we should return the first frame that
isn't filtered by the backtrace cleaner.
The puma documentation and code seem to disagree about
whether `preload_app!` is the default depending on the number
of workers.
Worst case it's the default and making it explicit is no big deal.
When the application has more than one database configuration, only
the primary was being loaded by default on boot time. All the other
connection pools were loading the schema cache lazily.
This logic can be found in:
351a8d9bc9/activerecord/lib/active_record/connection_adapters/pool_config.rb (L13)351a8d9bc9/activerecord/lib/active_record/railtie.rb (L149-L178)
The lazy code path wasn't using the same logic to determine the name
of the default schema cache file that the Railties uses, so it
was loading the schema cache of the primary config to all the other
configs. If no table name coincided nothing bad would happen, but if
table names coincided, the schema would be completly wrong in all
non-primary connections.
In a [previous commit][1], the App Generator skeleton test was updated
to verify the exact file output when generating a new application. This
commit applies the same change to the Plugin Generator.
At first, I was hesitant to add the list of dummy app files to the
`default_files` for the Plugin Generator test, however it quickly became
apparent that it was a good idea. Making this change exposed that recent
file additions to the App Generator were added to the plugin's dummy app
as well. Things like CI files, rubocop configuration, and a brakeman
command should not be created for a dummy app, and are now properly
excluded.
Similar to the App Generator commit, this change also removes tests that
are now redundant due to the skeleton test verifying the exact list of
files generated.
[1]: e5e4b801046bceb1067ffb316edd1ad704b6596d
Previously, the skeleton test would assert that every file in the
`default_files` list existed. However, since there is no requirement
that a file is added to this list when added to the generator the list
can (and has) become out of sync with the exact generated output.
This commit refactors the skeleton test to gather the full list of files
created by the generator so that it can be compared exactly to the list
of `default_files`. This ensures the generated file list must be updated
when any file is added or removed from the generator. Additionally, by
using array equality the sorting of the `default_files` list is enforced
(it was previously _mostly_ alphabetical, but not fully).
The new skeleton test assertion was written to only assert files instead
of folders for a few reasons:
- asserting that folders exist is redundant if a file exists within a
folder (and the `default_files` list would be significantly longer
with all folders)
- any folder generated without any files inside it will not be tracked
by Git, so other code cannot assume these empty folders exist
Because of these reasons, this patch also includes a change to no longer
generate the `tmp/cache/assets` folder by default. The folder is an
implementation detail of Sprockets and doesn't need any special
treatment in Rails. The `Sprockets::Cache::FileStore` will create the
directory if it does not exist (which it usually won't since `tmp/cache`
is excluded from Git by the `.gitignore`), and the `tmp:cache:clear`
task already clears all subdirectories of `tmp/cache`.
Finally, some tests making assertions about the default output of the
app generator were removed as they have been made redundant by the
improvements to the skeleton test.