There is no reason to expose all those details to users and this
has the benefit that now are can ensure that the YJIT is enabled
after all initialization is done.
Postgresql's database.yml has devcontainer specific logic that should only appear when the app has a devcontainer. We need the DevcontainerGenerator to update database.yml, so when it is called by the devcontainer command the database.yml will have the right configuration.
This commit also fixes db:system:change to make sure it updates the database.yml with the correct devcontainer configuration.
Instead of relying on the template to be dev container aware and generate the correct configuration, let's just update the configuration in place when running the DevcontainerGenerator. This will allow the devcontainer command to update this file with the configuration needed for devcontainers without overwriting the entire file.
For Rails 7.2 we will make devcontainer and opt-in feature for new applications. When creating a new app, you can generate a devcontainer by passing the --devcontainer flag.
Configuring a persistent storage volume in Kamal
is needed only for sqlite or Active Storage. If
using a different database or the
--skip-active-storage option, this configuration
can be skipped.
The storage/ directory is used for sqlite or
Active Storage. If using a different database
and the --skip-active-storage option, this
directory is not needed.
Minitest will now exit 1 when a `-n` type test filter is used and no
test cases end up being run. However, these tests are not really
concerned with the exit code, just that `test:prepare` doesn't run.
This commit adds `allow_failure: true` to the test command invocations
so that we can continue to test whether `test:prepare` is run without
caring about the exit status of the test command.
Extract all the DB information (gems, dockerfile packages, devcontainer etc.) into an object. This let's us remove the growing number of case statements in this code.
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.
