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]: e5e4b80104
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.
At GitHub we get a fair number of Trilogy `ETIMEDOUT` errors (for known
reasons that we might be able to improve somewhat, but I doubt we'll
make them go away entirely). These are very much retryable network
errors, so it'd be handy if these `ETIMEDOUT` errors were translated to
`ConnectionFailed` instead of `StatementInvalid`, making them
`retryable_connection_error`s.
ed2bc92b82/activerecord/lib/active_record/connection_adapters/abstract_adapter.rb (L1077)
We're already translating `ECONNRESET` (via matching on the error
message) and `EPIPE` to `ConnectionFailed`. Rather than adding another
case, this commit treats all of the Trilogy `SystemCallError` subclasses
as `ConnectionFailed`.
This requires bumping trilogy 2.7 so we can get
https://github.com/trilogy-libraries/trilogy/pull/143
Following the discussion in #50770, the new format will be:
`[dasherized-app-name]([colorized-env])>`
For example, if the app's module name is `MyApp`, the prompt will be:
`my-app(dev)>`, where the `dev` part will be colored.
Update railties/lib/rails/commands/console/console_command.rb
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Update changelog
Setting `TERM=dumb` is enough to disable colorization in those tests.
Mocked app should also load console helpers
Move console method extension to IRBConsole's constructor
Test IRB autocompletion control without mutating ENV
Control IRB autocompletion without mutating ENV
Correct local variable name
When Rake parses an argument string with no tasks, it sets the top-level
task as "default". Prior to this commit, if no default task was defined
(for example, if an app was generated with `--skip-test` and didn't
define its own default task), `Rails::Command::RakeCommand` would raise
`UnrecognizedCommandError`, preventing Rake from displaying the task
list.
This commit changes `Rails::Command::RakeCommand` to let Rake handle the
"default" task.
Fixes#50700.
Prior to this commit, `bin/rails` would pass unrecognized bare options
on to Rake:
```console
$ bin/rails -v
Rails 7.2.0.alpha
$ bin/rails -V
rake, version 13.0.6
$ bin/rails -s
Running 0 tests in a single process (parallelization threshold is 50)
...
$ bin/rails -S
invalid option: -S
```
This commit changes `bin/rails` to print its help message when given an
unrecognized bare option:
```console
$ bin/rails -v
Rails 7.2.0.alpha
$ bin/rails -V
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
$ bin/rails -s
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
$ bin/rails -S
Usage:
bin/rails COMMAND [options]
You must specify a command. The most common commands are:
...
```
However, for backward compatibility, an exception has been made for the
`-T` / `--tasks` option:
```console
$ bin/rails -T
# Prints list of Rake tasks...
```
Addresses #50712.
The Rails documentation uses the `:include:` directive to inline the
README of the framework into the main documentation page. As the
README's aren't in the root directory from where SDoc is run we need to
add the framework path to the include:
# :include: activesupport/README.md
This results in a warning when installing the gems as generating the rdoc for the gem is run from the gem/framework root:
Couldn't find file to include 'activesupport/README.rdoc' from lib/active_support.rb
The `:include:` RDoc directive supports includes relative to the current
file as well:
# :include: ../README.md
This makes sure it works for the Rails API docs and the separate gems.
Co-authored-by: Jonathan Hefner <jonathan@hefner.pro>
This hook was only running when routes were reloaded, but not on boot.
The goal was to run any time routes are loaded. This commit fixes it
and adds a test.
Fixes#50720.
Previously, some files put under `app` directory would contaminate the load paths.
This commit removes files from the default load paths set up by the Rails framework.
Now, only directories are included as default in the following paths:
* autoload_paths
* autoload_once_paths
* eager_load_paths
* load_paths
Previously, the Rails application would reload due to changes
in some files outside the autoload paths.
For instance, editing `app/README.md` would trigger a reload,
even though the reloaded classes and modules were identical
to those loaded previously.
This commit fixes this issue by ensuring the application reloads correctly
according to `Rails.autoloaders.main.dirs`, thereby preventing unnecessary reloads.
https://github.com/rails/rails/issues/37011#issuecomment-1322560651
The main change is the default number of threads
is reduced from 5 to 3 as discussed in https://github.com/rails/rails/issues/50450
Pending a potential future "Rails tuning" guide, I tried
to include in comments the gist of the tradeoffs involved.
I also removed the pidfile except for development.
It's useful to prevent booting the server twice there
but I don't think it makes much sense in production,
especially [since Puma no longer supports daemonization
and instead recommend using a process
monitor](99f83c50fb/docs/deployment.md (should-i-daemonize)).
And it makes even less sense in a PaaS or containerized
world.
* Remove pidfile in production
* Update changelog
* Update activestorage/test/dummy/config/puma.rb
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Update template and other dummy files
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
RDoc treats consecutive indented lines as a single code block. For code
examples that span multiple files / languages, this confuses the syntax
highlighter and makes the examples harder to read. Unfortunately, RDoc
doesn't provide syntax to prevent this, and it ignores multiple
consecutive blank lines. However, by inserting an empty tag such as
`<code></code>`, we can force RDoc to recognize separate code blocks.
While working on [another PR][1], I found that removing the
Transfer-Encoding conditionals did not result in any failing tests in
Action Pack. This was surprising to me until I found that there was a
test for this behavior in Railties. However, nothing about the test
really depends on having a full Rails application or the Railties test
suite.
This commit moves the test into Action Pack to simplify/speedup the test
(no need to build a full app) as well as keeping the test closer to the
actual behavior being tested.
[1]: 0c334b48fdc5d70b0c8406ba184fbfd26750b049
Jean Boussier