The [deprecated secrets removal][1] ended up removing a bit of
non-deprecated functionality related to config.secret_key_base:
- the original implementation prioritized the value of
config.secret_key_base over other sources in all environments
- if unset, the value of config.secret_key_base would be updated to
whichever fallback value was found
The new implementation only sets config.secret_key_base to a fallback
value when Rails.env.local?, and never considers it at all in
production.
This commit aims to restore this missing functionality as well as
simplify the implementation:
- Rails.application.secret_key_base now always delegates to
config.secret_key_base (like the pre-secret-removal implementation)
- secret_key_base validation was moved from the reader to the writer
- config.secret_key_base now handles setting itself to a fallback value
when unset
- In addition, generate_local_secret was simplified because it
previously did 3 things: file manipulation, setting
config.secret_key_base, and returning a value. Now it only creates the
file if necessary and returns the value stored in it
The new implementation has an additional benefit, which is that manually
set config.secret_key_base values are now validated, whereas previously
only fallback values were validated.
[1]: 0c76f17f2d
Co-authored-by: Petrik <petrik@deheus.net>
And stop exposing the capybara server port to all interfaces.
We were using this just to make sure the selenium container can access
the capybara server but it can with the default bridge network.
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.
This will make sure we have less tests to run since those are slow.
Generate the app once and run many assertions on it instead of generating
the same app multiple times.
Since we are stubbing bundle commands, we can avoid sprockets side-effects here.
This commit also fixes the tests for preservation of sprockets during `app:update`.
Due to propshaft being the default, this test was unnecessary.
Since 27285e7881 the special case for this gem was removed from the
codebase.
So changed this test to be about where we expect to find the
session stores.
When #48269 was merged any gem installed during `rails new` which calls `app:template` would cause the install command to be executed and consequently `bundle install` would also run.
We want to avoid running these commands in our tests because they are very expensive.
It is up to the gem (importmap, etc) to test the behavior of the install command, not railties.
Before
```
$ bin/test test/generators/plugin_generator_test.rb test/generators/app_generator_test.rb
Finished in 320.803659s, 0.8541 runs/s, 7.1913 assertions/s.
274 runs, 2307 assertions, 14 failures, 0 errors, 0 skips
```
After
```
Finished in 70.316250s, 3.9251 runs/s, 34.3164 assertions/s.
276 runs, 2413 assertions, 0 failures, 0 errors, 0 skips
```
Checking explicitly against `test` break extensions that provide their
own methods to generate tests, like `minitest-spec-rails` or `minitest-rails`.
Fixes#51956
The `registry.docker.com` registry isn't documented and have a delay
when pulling images. The `docker.io` registry is the default registry
for Docker images and is the one used by the Docker CLI.
* Change asset pipeline default to Propshaft
* Use :all for stylesheets when propshaft is active
* Switch to using propshaft as the default (still need to find a way to tests against sprockets too)
* Fix tests that rely on sprockets being used
* Fix Propshaft tests (#51913)
* Update railties/test/generators/shared_generator_tests.rb
Co-authored-by: Lázaro Nixon <lazaronixon@hotmail.com>
---------
Co-authored-by: Lázaro Nixon <lazaronixon@hotmail.com>
Add tests to verify the app and helpers files deprecation / backwards
compatibility, and remove the `.rb` extension from the message, since we
generally require without them.
Follow up to #51891
This resolves the following test failure:
https://buildkite.com/rails/rails/builds/107520#018fa76e-0408-4630-a75d-eac5caa16463/1199-1209
```
Failure:
ApplicationTests::ConfigurationTest#test_SQLite3Adapter.strict_strings_by_default_can_be_configured_via_config.active_record.sqlite3_adapter_strict_strings_by_default_in_an_initializer [test/application/configuration_test.rb:2896]:
Expected /no such column: non_existent/ to match "SQLite3::SQLException: no such column: \"non_existent\" - should this be a string literal in single-quotes?".
```
Co-authored-by: Mike Dalessio <mike.dalessio@gmail.com>
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.
Rafael Mendonça França