Currently when you generate a project the compose.yaml generated
file does not include the top-level name property. Not having this
top-level name property makes all containers / volumes started by
devcontainer to be prepended with the folder name, which is
`devcontainer` in the case of the .devcontainer/compose.yml` file.
This is ok if you run only one project with devcontainer but starts
to get problem if you run multiple projects. If you have one project
that runs on postgresql 15 and a new one that runs on postgresql 16 it
will fail to boot the postgresql container because both devcontainers is
using the same volume: `devcontainer_postgres-data`.
This commit fixes this by setting the top-lavel name property with
the project name, which will make the containers and volumes to be
prepended with the project name and not with `devcontainer`.
Follow up #51782.
> But it's overkill for the default case where people use the default style guide,
> and it introduces both delay and console output as a cost.
When there are no offenses with the coding style generated by code generation,
outputting RuboCop results to the console was redundant.
Since RuboCop has `--format=quiet` option that suppresses console output
when there are no offenses, this PR adds that option:
https://docs.rubocop.org/rubocop/1.63/formatters.html#quiet-formatter
While this PR doesn't resolve any added execution speed by RuboCop,
the frequency of using the generator is not high within the development flow.
Therefore, depending on the execution speed, it might be possible to uncomment #51782,
but this PR respects the defaults in #51782 and doesn't address that.
Without the sleep, the test has high variability in the amount of test
ran before stopping. With the sleep, the test is pretty stable with
negligeable impact on run time.
Executes the first routes reload in middleware, or when the route set
url_helpers is called. Previously, this was executed unconditionally on
boot, which can slow down boot time unnecessarily for larger apps with
lots of routes.
Due to some users/libs relying on Rails::ConsoleMethod to extend Rails
console, we need to keep including it to IRB's internal.
But to prevent also adding `app` and `helper` methods to the console,
which are already registered to IRB through its API, we need to remove
them from the Rails::ConsoleMethods. Additionally, we should raise
deprecation warning when users try to use Rails::ConsoleMethods in this
way.
This commit:
- Removes all methods from Rails::ConsoleMethods that are already
registered to IRB. So it's now essentially empty.
- Raises a deprecation warning when modules are included to Rails::ConsoleMethods
or methods are added to it.
- Adds a test to ensure that the deprecation warning is raised and the
methods are available in the console.
Instead, the app's name should be set via a separate IRB config, which
will allow it to be changed at runtime.
Co-authored-by: Mike Dalessio <mike.dalessio@gmail.com>
This will greatly increase the visibility of Rails console commands and helpers,
and stop rely on IRB's internal components.
Extension API reference: https://github.com/ruby/irb/blob/master/EXTEND_IRB.md
And because we need to create new classes to use the new APIs, I also
moved all the IRB-specific code to a new file, `irb_console.rb`.
Use IRB.conf[:BACKTRACE_FILTER] for backtrace filtering in console
This change uses the new `IRB.conf[:BACKTRACE_FILTER]` to inject the backtrace
filtering logic into IRB. This avoids the need to patch IRB's internal
WorkSpace class.
Update changelog
rails/rails@957a3e5 allowed the BACKTRACE env to unsilence backtraces in normals runs not just tests. However, the implementation achieves this by removing the silences in an initializer. This means that the state of backtrace silencer becomes cached by spring and the developer needs to reset spring every time they want to silence or unsilence the backtrace. It also means custom silencers added in an initializer need to be added after the :configure_backtrace_cleaner initializer or else they won't be un-silenced properly.
Instead, let's teach Rails::BacktraceCleaner to unsilence the backtrace if the BACKTRACE variable is set. ActiveSupport::BacktraceCleaner#clean already allows this by passing nil as the second argument, which just filters but does not silence the backtrace. So, in Rails::BacktraceCleaner#clean we can call super with nil in the second argument if the BACKTRACE variable is present. That way we do not need to remove the silencers in an initializer, and we don't have to reset spring to silence the backtrace.
This specifically is affecting the mysql and mariadb ALLOW_EMPTY_PASSWORD flag. It seems VSCode is doing something to handle coercing these to strings, but an issue occurs when using docker-compose on this file.
We have created our own features for optional Rails dependencies needed for active storage, postgres and mysql. Features provide a bit better ergonomics for adding or removing these from the devcontainer, and previously we were always installing these dependencies via the devcontainer's dockerfile, whether the app was using them or not.
With this change, when we generate the app, we just add the features we need to the devcontainer.json. And also, we swap features in and out as need when doing db:system:change.
RFC 9110 specifies:
The server MUST send an Upgrade header field in a 426 response
to indicate the required protocol(s)
https://httpwg.org/specs/rfc9110.html#status.426
Status 406 Not Acceptable is more appropriate because it indicates the
resource
does not have a current representation that would be acceptable
to the user agent, according to the proactive negotiation header
fields received in the request
https://httpwg.org/specs/rfc9110.html#status.406
With the proactive negociation section mentionining:
implicit characteristics, such as the client's network address
or parts of the User-Agent field.
https://httpwg.org/specs/rfc9110.html#proactive.negotiation
This commit addresses Rails Nightly CI failure
at https://buildkite.com/rails/rails-nightly/builds/391#018ec54f-a2ef-40de-9749-6cc3ecae4ebd/1368-1376
```ruby
$ ruby -v
ruby 3.4.0dev (2024-04-09T16:29:01Z master 0107954f25) [x86_64-linux]
$ bin/test test/command/help_integration_test.rb:33
Run options: --seed 3363
F
Failure:
Rails::Command::HelpIntegrationTest#test_prints_help_via_`X:help`_command_when_running_`X`_and_`X:X`_command_is_not_defined [test/command/help_integration_test.rb:37]:
--- expected
+++ actual
@@ -1,4 +1,5 @@
-"Commands:
+"/home/yahonda/.rbenv/versions/trunk/lib/ruby/gems/3.4.0+0/gems/zeitwerk-2.6.13/lib/zeitwerk/kernel.rb:34: warning: ostruct was loaded from the standard library, but will no longer be part of the default gems since Ruby 3.5.0. Add ostruct to your Gemfile or gemspec.
+Commands:
bin/rails dev:cache # Toggle development mode caching on/off
bin/rails dev:help [COMMAND] # Describe available commands or one specific...
bin/test test/command/help_integration_test.rb:33
Finished in 0.738986s, 1.3532 runs/s, 1.3532 assertions/s.
1 runs, 1 assertions, 1 failures, 0 errors, 0 skips
$
```
This commit can be reverted once both rack and jbuilder take care of it.
Related to
https://github.com/rack/rack/pull/2166https://github.com/rails/jbuilder/issues/561
`ostruct` was being implictly required by the `json` gem. But once it
was upgraded, these tests failed to initialize `OpenStruct`.
While we're trying to remove `ostruct` usage in #51510, CI is currently
failing so I'm pushing these in the mean time.
This is useful for testing changes to how the devcontainer is generated, and will be necessary for creating a CI workflow for testing the devcontainer setup.
If running in an interactive console, the user will be given the option to correct the error and re-run the tests.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
## Motivation / Background
An issue was identified where an error occurs when executing `apply_rubocop_autocorrect_after_generate!` with `--pretend` option,
according to feedback from https://github.com/rubocop/rubocop-rails/pull/1263.
## Details
This PR fixes the following error when executing `apply_rubocop_autocorrect_after_generate!` with `--pretend` option:
```console
$ bin/rails g migration create_users -p
```
### Before
An `Errno::ENOENT` error occurs:
```console
invoke active_record
create db/migrate/20240329060627_create_users.rb
/Users/koic/.rbenv/versions/3.3.0/lib/ruby/gems/3.3.0/bundler/gems/rails-8e46af8c9396/railties/lib/rails/configuration.rb:138:in
`system': No such file or directory - bin/rubocop (Errno::ENOENT)
```
### After
No errors.
Skip generating a `test` job in ci.yml when a new application is
generated with the `--skip-test` option.
Co-authored-by: Rafael Mendonça França <rafael@rubyonrails.org>
For example, if you run `rails test test/models/usr_tsst.rb` and the file does not exist,
Rails will suggest `test/models/users_test.rb` as a possible file.
```
Could not load test file: test/models/usr_tsst.rb. Did you mean? test/models/user_test.rb
```
Co-authored-by: Aaron Patterson <aaron@rubyonrails.org>
Replaced by `#lease_connection` to better reflect what it does.
`ActiveRecord::Base#connection` is deprecated in the same way
but without a removal timeline nor a deprecation warning.
Inside the Active Record test suite, we do remove `Base.connection`
to ensure it's not used internally.
Some callsites have been converted to use `with_connection`,
some other have been more simply migrated to `lease_connection`
and will serve as a list of callsites to convert for
https://github.com/rails/rails/pull/50793
Extracted from: https://github.com/rails/rails/pull/50793
Similar to the recent refactoring of schema caches, rather than to directly
hold a connection, they now hold a pool and checkout a connection when needed.
https://buildkite.com/rails/rails-nightly/builds/191#018dc3d1-902c-4b01-a82c-b662ebdbe567/1182-1188
Increasing timeout value from 10 to 100 for assert_output method addresses these failures.
- Ruby built with debug options that takes more than 20 seconds and gets failed
Here, the Ruby is built with these options:
```
cppflags="-DENABLE_PATH_CHECK=0 -DRUBY_DEBUG=1" optflags="-O3 -fno-inline"
```
```ruby
$ ruby -v
ruby 3.4.0dev (2024-02-20T11:52:09Z master c22cb960cf) [x86_64-linux]
$ time bin/test test/application/dbconsole_test.rb
Run options: --seed 5685
F
Failure:
ApplicationTests::DBConsoleTest#test_use_value_defined_in_environment_file_in_database_yml [test/console_helpers.rb:19]:
"sqlite>" expected, but got:
.
Expected "" to include "sqlite>".
bin/test test/application/dbconsole_test.rb:21
F
Failure:
ApplicationTests::DBConsoleTest#test_respect_environment_option [test/console_helpers.rb:19]:
"sqlite>" expected, but got:
.
Expected "" to include "sqlite>".
bin/test test/application/dbconsole_test.rb:43
Finished in 10.105668s, 0.1979 runs/s, 0.3958 assertions/s.
2 runs, 4 assertions, 2 failures, 0 errors, 0 skips
real 0m21.031s
user 0m8.665s
sys 0m2.286s
$
```
- Ruby built without debug options that finishes within second.
```ruby
$ ruby -v
ruby 3.4.0dev (2024-02-20T11:52:09Z master c22cb960cf) [x86_64-linux]
$ time bin/test test/application/dbconsole_test.rb
Run options: --seed 1479
..
Finished in 5.463076s, 0.3661 runs/s, 1.0983 assertions/s.
2 runs, 6 assertions, 0 failures, 0 errors, 0 skips
real 0m9.942s
user 0m2.288s
sys 0m2.173s
$
```
This commit address Rails Nightly failure at
https://buildkite.com/rails/rails-nightly/builds/191#018dc3d1-8fb2-4c35-ad1d-bd3891757361/1310-1318
This issue reproduces when the `default-mysql-client` apt package installs `mysql-client-8.0`
that raises `CR_CONN_HOST_ERROR` which is mapped to `ActiveRecord::DatabaseConnectionError`
while `mariadb-client` raises `CR_CONNECTION_ERROR` error which is mapped to `ActiveRecord::ConnectionNotEstablished`.
In this test, whichever exception `ActiveRecord::ConnectionNotEstablished` or `DatabaseConnectionError` is fine
as long as the connection is invalid.
- Steps to reproduce
Run this step at Linux box on Ubuntu Jammy or whatever `default-mysql-client` installs MySQL client, not MariaDB one.
```
git clone https://github.com/rails/rails
cd rails/railties
bundle install
bin/test test/application/initializers/frameworks_test.rb:285
```
- Failure fixed by this commit
```ruby
$ bin/test test/application/initializers/frameworks_test.rb:285
Run options: --seed 32832
F
Failure:
ApplicationTests::FrameworksTest#test_expire_schema_cache_dump_if_the_version_can't_be_checked_because_the_database_is_unhealthy [test/application/initializers/frameworks_test.rb:285]:
Expected /Failed to validate the schema cache because of ActiveRecord::ConnectionNotEstablished/ to match "Failed to validate the schema cache because of ActiveRecord::DatabaseConnectionError: There is an issue connecting with your hostname: 127.0.0.1.\n\nPlease check your database configuration and ensure there is a valid connection to your database.\n".
bin/test test/application/initializers/frameworks_test.rb:263
Finished in 6.299418s, 0.1587 runs/s, 0.6350 assertions/s.
1 runs, 4 assertions, 1 failures, 0 errors, 0 skips
```
- `default-mysql-client` package used by Rails CI
3158d00b48/Dockerfile (L91)
`default-mysql-client` installs different package per distribution, Ja
https://packages.ubuntu.com/jammy/default-mysql-clienthttps://packages.debian.org/bookworm/default-mysql-client
- Each error message are defined in these lines by these commits:
-- MariaDB
eeba940311/sql-common/errmsg.c (L32)9075973dbf
-- MySQL
824e2b4064/libmysql/errmsg.cc (L39)964d5fdb02
Another refactoring in relation to https://github.com/rails/rails/pull/50793
But it makes sense even without it.
Rather than each connection to have its own `BoundSchemaReflection`,
we can instead have `BoundSchemaReflection` hold a `ConnectionPool`,
from which it can checkout a connection to perform queries when needed.
If the current thread already leased a connection, it will be used.
This simplifies the interface quite a bit.
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>
This reverts commit 6985c3bedf, reversing
changes made to 3163bb7351.
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.
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.
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]: e5e4b80104
Cadu Ribeiro