This require was removed in 576fb33ba3c1cf0a0c3e83ffac56c46a83d7a57f,
after 8513769ad60f68d084e487550162b9d3766aea77 removed the deprecation
that originally added it in 29b16d3ff87a3da4ec4ac33a17ad9fd9540284c8.
In between however, 0983daa4aa5f6bec96254af907b9956b804faddc added
another deprecation to this file, so the require is still necessary.
Fixes#40575.
Since #37850, `config_for` returns `nil` instead of an empty Hash when
a config file does not contain configuration for the specified
environment. Thus, the return value should be converted to a Hash
before calling `with_indifferent_access`.
Fixes#40548.
After Puma's version 5, a worker timeout check was added, causing all
debugging sessions (byebug, binding.irb, ...) to be terminated after a
minute is passed.
One minute timeout is fine for production environments but not for
development, when we usually debug stuff and need more than a minute to
do so.
This PR updates Puma's config template file to include a worker timeout
of one hour, only for development environments.
In the same way that requests may need to be excluded from forced SSL,
requests may also need to be excluded from the Host Authorization
checks. By providing this additional flexibility more applications
will be able to enable Host Authorization while excluding requests
that may not conform. For example, AWS Classic Load Balancers don't
provide a Host header and cannot be configured to send one. This means
that Host Authorization must be disabled to use the health check
provided by the load balancer. This change will allow an application
to exclude the health check requests from the Host Authorization
requirements.
I've modified the `ActionDispatch::HostAuthorization` middleware to
accept arguments in a similar way to `ActionDispatch::SSL`. The hosts
configuration setting still exists separately as does the
hosts_response_app but I've tried to group the Host Authorization
settings like the ssl_options. It may make sense to deprecate the
global hosts_response_app if it's only used as part of the Host
Authorization failure response. I've also updated the existing tests
as the method signature changed and added new tests to verify the
exclusion functionality.
- This is similar to other railties blocks (such as `console`,
`tasks` ...). The goal of this block is to allow the application
or a railtie to load code after the server start.
The use case can be to fire the webpack or react server in
development or start some job worker like sidekiq or resque.
Right now, all these tasks needs to be done in a separate
shell and gem maintainer needs to add documentation on
how to run their libraries if another program needs to run
next to the Rails server.
This feature can be used like this:
```ruby
class SuperRailtie < Rails::Railtie
server do
WebpackServer.run
end
end
```
Follow-up to #34218.
This removes some filters that could filter innocuous fields such as
`author_name`. Filtering such fields might be surprising, especially to
people generating their first Rails app.
This commit also changes the `:password` filter to `:passw` so that it
can also filter fields such as `passwd`.
by setting `config.action_dispatch.request_id_header` to the desired value
* Ensure HTTP_X_REQUEST_ID presence to maintain compatiblility
* Use req.headers[] to fetch header rather than ENV methods
* Update configuration doc to match existing descriptions
* Add changelog entry for action_dispatch.request_id_header
This change allows for a connection to be swapped on role or shard for a
class. Previously calling `connected_to` would swap all the connections
to a particular role or shard. Granular connection swapping is useful
for swapping one connection to reading while leaving all other
connection classes on writing.
The public methods on connection handler have been updated to behave the
same as they did previously on the different handlers. The difference
however is instead of calling
`ActiveRecord::Base.connection_handlers[:reading].clear_all_connections!`
you now call
`ActiveRecord::Base.connection_handler.clear_all_connections!` which
will clear based on current role set by a `connected_to` block. Outside
the context of a `connected_to` block, `clear_all_connections!` can take
an optional parameter to clear specific connections by role.
The major changes in this PR are:
* We introduced a `legacy_connection_handling` configuration option that
is set to true by default. It will be set to `false` for all new
applications.
* In the new connection handling there will be one only connection
handler. Previously there was a connection handler for each role. Now
the role is stored in the `PoolManager`. In order to maintain backwards
compatibility we introduced a `LegacyPoolManager` to avoid duplicate
conditionals. See diagram in PR body for changes to connection
management.
* `connected_to` will now use a stacked concurrent map to keep track of
the connection for each class. For each opened block the `class`,
`role`, and `shard` will be added to the stack, when the block is exited
the `class`, `role`, `shard` array will be removed from the stack.
* With these changes `ActiveRecord::Base.connected_to` will remain
global. If called all connections in the block will use the `role` and
`shard` that was switched to. If called with a parent class like
`AnimalsRecord.connected_to` only models under `AnimalsRecord` will be
switched and everything else will remain the same.
Examples:
Given an application we have a `User` model that inherits from
`ApplicationRecord` and a `Dog` model that inherits from
`AnimalsRecord`. `AnimalsRecord` and `ApplicationRecord` have writing
and reading connections as well as shard `default`, `one`, and `two`.
```ruby
ActiveRecord::Base.connected_to(role: :reading) do
User.first # reads from default replica
Dog.first # reads from default replica
AnimalsRecord.connected_to(role: :writing, shard: :one) do
User.first # reads from default replica
Dog.first # reads from shard one primary
end
User.first # reads from default replica
Dog.first # reads from default replica
ApplicationRecord.connected_to(role: :writing, shard: :two) do
User.first # reads from shard two primary
Dog.first # reads from default replica
end
end
```
Things this PR does not solve:
* Currently there is no API for swapping more than one but not all
connections. Apps with many primaries may want to swap 3 but not all 10
connections. We plan to build an API for that in a followup PR.
* The middleware remains the same and is using the global switching
methods. Therefore at this time to use this new feature applications
must manually switch connections. We will also address this in a
followup PR.
* The `schema_cache` is currently on the `PoolConfig`. We plan on trying
to move this up to the `PoolManager` or elsewhere later on so each
`PoolConfig` doesn't need to hold a reference to the `schema_cache`.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
In #39632, `boot.rb` was changed to load `bin/spring`, with the
intention of adding a check to Spring itself that would prevent Spring
from running in production environments. However, in a production
environment, the Spring gem may not be installed. Furthermore,
`bin/spring` may raise an error other than `LoadError` if it has been
overwritten by e.g. `bundle binstubs` as part of the deployment process.
Therefore, this commit adds the environment check to `boot.rb`.
This commit also changes the app generator to generate `bin/spring`
directly, instead of delegating to `bundle exec spring binstub`. This
addresses an issue with the `--skip-bundle` flag. Previously,
`--skip-bundle` caused `bin/spring` to not be generated. Thus the user
had to manually run `bundle exec spring binstub` later, though that was
not documented nor explained. Now, `bin/spring` is always generated.
Additionally, by guaranteeing that `bin/stub` is generated, we avoid the
need for `rescue LoadError` in `boot.rb`.
* Refactor railsrc file location to be xdg compliant
The XDG Base Directory Specification (which is currently used by
FOSS projects such as Git, Tmux, Pry, Rspec) provides a default
location for various file formats, including config/rc files.
This comment refactors app_generator.rb to load railsrc from
XDG_CONFIG_HOME if both XDG_CONFIG_HOME is set and rails/railrc
exists within the XDG_CONFIG_HOME location.
To maintain backwards compatibility it defaults back to ~/.railsrc
if either XDG_CONFIG_HOME is not set or there is no rails/railsrc.
* Refactor default_rc_file based on jonathanhefner PR feedback
* Update generators/rails/app/USAGE to explain railsrc XDG compliance
* Refactor default_rc_file based on sinsoku PR feedback
* Add test for ARGVScrubber.default_rc_file method
fileutils is required because tmpdir does not allow you to create a new
temp directory with a set title 'inside' another temporary directory, a
file is created for railsrc because tempfile creates a custom and unique
name preventing the specification of a file called 'railsrc'
Currently this test is failing because the ARGVScrubber class seems to
be loading directly from the gem (which still has the previous code)
rather than from the file itself. (loading the code in a pry session
and using show-method ARGVScrubber.default_rc_file reveals it is coming
from
gems/railties-6.0.3.3/lib/rails/generators/rails/app/app_generator.rb:536
instead of
railties/lib/rails/generators/rails/app/app_generator.rb
* Switch to double quote strings
* Add file deletion for argv_scrubber test
* Refactor test_xdg_config_no_custom_rc with jonathanhefner feedback
* Add Changelog for railsrc xdg-specification compliance
* Apply backtick and whitespace refactoring suggestsions from jonathanhefner
* Apply jonathanhefner suggested Changelog refactoring
[Rafael Mendonça França + Nick Wolf + Jonathan Hefner]
Currently when a new rails app is created it uses the app name as it and puts
it in the package.json name. According to npm and JS standards package names
do not have capital letters and should not be using the PascalCase that is
used in Rails app name. This change is to convert app name to using snake case
but with dashes
`Minitest.plugin_rails_init` sets `Minitest.backtrace_filter` to
`Rails.backtrace_cleaner` right before tests are run, overwriting the
value set in test_helper.rb.
`Rails.backtrace_cleaner` silences backtrace lines that do not start
with `Rails.root` followed by e.g. "lib/" or "test/". Thus when
`Rails.root` is a subdirectory of the project directory -- for example,
when testing a plugin that has a dummy app -- all lines of the backtrace
are silenced.
This commit adds a fallback such that when all backtrace lines are
silenced, the original `Minitest.backtrace_filter` is used instead.
Additionally, this commit refactors and expands existing test coverage.
Each stacked operation is a Proc object instead of operation name since fedde239dcee256b417dc9bcfe5fef603bf0d952,
and so we can now simply inline the target method for each operation
Permit applications to hack in custom DB config for ASt models until ASt has first-class multi-DB support:
ActiveSupport.on_load(:active_storage_record) do
connects_to reading: :active_storage_replica, writing: :active_storage_primary
end
rebase
Sometimes cascading association deletions can cause timeouts due to
an IO issue. Perhaps a model has associations that are destroyed on
deletion which in turn trigger other deletions and this can continue
down a complex tree. Along this tree you may also hit other IO
operations. Such deep deletions can lead to server timeouts while
awaiting completion and really the user may not notice all the
changes on their side immediately making them wait unnecesarially or
worse causing a timeout during the operation.
We now allow associations supporting the `dependent:` key to take `:destroy_async`,
which schedules a background job to destroy associations.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Co-authored-by: Cory Gwin @gwincr11 <gwincr11@github.com>
Right now it's already possible to set a digest class manually, but this
is not through a publicly supported and approved API. With these
configuration options, it is possible to configure a digest class to use
for digests inside Rails.
The reason for this is that it allows configuring other classes in
certain conditions like running in FIPS mode. FIPS disallows MD5 and
discourages SHA1. Even though this isn't used in Rails for security
related things, using newer hash algorithms means not having to explain
it to auditors which always makes life easier.
That's not the only reason though. If today Ruby is built and running
for example in an Ubuntu 18.04 FIPS approved environment, the default
Digest classes break, see https://bugs.ruby-lang.org/issues/13681 as
well.
By allowing a class to be configured, the following can be used so that
things work properly (using the new API proposed here):
```
Rails.application.config.active_support.hash_digest_class = OpenSSL::Digest::SHA256
```
This would then use the OpenSSL certified FIPS implementation as well.
.gitattributes files are a useful way to mark certain metadata about paths in a git repository (https://git-scm.com/docs/gitattributes). This can include all kinds of information, but one of the more useful ones is that linguist (https://github.com/github/linguist, the tool that powers the language statistics/diff view of GitHub) respects certain attributes. For example:
* `linguist-vendored` paths will not be counted toward the language statistics
* `linguist-generated` paths will not have their diff shown by default
These little niceties can be really helpful over time, so we should add it to the default app generator.
I recently learned that Rails logs at the :debug level (not the :info
level) by default in production environments. This is a surprising
behaviour, as other popular frameworks do not log at this level
by default. It would not be surprising if a developer accidentally
logged personally identifiable information (PII) in a production
environment due to this behaviour.
I noticed that [in 2014](https://github.com/rails/rails/pull/16622), the
Rails project made an intentional decision to set the default log level
to :debug. However, the landscape around logging PII has changed since
then with the introduction of legislation like GDPR, so I thought it
prudent to reopen this discussion.
Follow-up to #40143.
Rails Rake tasks are loaded for each new `Rake::Application` instance
via `Rails.application.load_tasks`. However, under the hood,
`Rails.application.load_tasks` used `require` instead of `load`, which
caused Rails tasks to be loaded for only the first `Rake::Application`
instance.
This commit changes the relevant `require` to `load`.
Fixes#40184.
The handling for single database applications has always set a schema.rb
or structure.sql files for loading the database schema. When we first
implemented multiple database support we intended to keep this for the
original, default database. Afterall Rails _has_ to connect to something
on boot. In development only one connection is connected on boot since
we don't eager load the app.
Originally we had thought that all applications should be required to
add a `primary` entry in the database configurations file. However,
this hasn't worked in practice and we have some code now that does not
assume there's a primary. The schema dumping/loading code however,
still assumed there was a "primary" in the configurations file.
We want the "default" database in any application to use the original
files even when converted to a multiple database application as this
reduces the need to make changes when implementing this functionality on
an existing application.
The changes here update Rails to ensure that we treat either "primary"
or the first database configuration for an environment as "default".
If there is a "primary" that will be used as the default configuration.
If there is no primary the configuration that is first for an
environment will be used as the default. For schema dump/load this means
that the default configuration (primary or first) will use `schema.rb`
as the filename and other configurations will use
`[CONFIGURATION_NAME]_schema.rb`.
This should also help us finish the pull request to infer migrations
paths since now we can say the first configuration is the default. This
is a natural assumption for application developers.
Followup to #39536
In #39137, a new `Rake::Application` instance was created per Rake
command invocation. To ensure that the Rails tasks were defined for
each `Rake::Application`, `rails/tasks.rb` was loaded per instance.
However, `Rake::Application#load_rakefile` loads the application's
Rakefile, which should invoke `Rails.application.load_tasks`, which, in
turn, also loads the Rails tasks. When a Rake task is defined more than
once, all definition blocks are executed when the task is run. Hence,
Rails task blocks were being executed twice.
This commit removes the unnecessary load and avoids double execution.
Fixes#40136.
This initializer should be best effort. If for some reason the
database in unhealthy, it is better to move forward with the
boot process than to crash.
Fixes#40031
While removing deprecated non-symbol access to nested `config_for`
hashes in #37876, we also broke `config_for` for anyone using the
[safe_yaml] gem. The problem is that `safe_yaml` patches `YAML.load` in
a way that doesn't honor the `symbolize_names` options (I believe this
is on purpose, to prevent symbol-based DOS attacks).
In the description of #37876 there is mention of the fact that this was
the first place in Rails we used `symbolize_names`, and that
`deep_symbolize_keys` had been used in the past.
This commit switches over to `deep_symbolize_keys` to allow `config_for`
to continue working for people using [safe_yaml].
[safe_yaml]: https://rubygems.org/gems/safe_yaml
Currently, the file generated via the generator is pluralized
but the parent class is singluar.
example: bundle exec rails g scaffold Pet name:string --database=animals
The above command should generate: apps/models/animals_record.rb
but the pets model would inherit from: `AnimalRecord` as
`"animals".classify` would be `Animal`
This will throw the `uninitialized constant AnimalRecord Did you mean? AnimalsRecord`
error.
For example, for a plugin like `my_plugin`, this makes the
`MyPlugin::VERSION` constant available to all consumers by default.
This commit also replaces the default generated test with a test that
the developer is less likely to delete.
On current master with multiple DBs configured, calling db:migrate:redo fails when trying to run db:rollback.
Before:
```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:rollback` you must run the namespaced task with a VERSION. Available tasks are db:rollback:primary and db:rollback:secondary.
Tasks: TOP => db:rollback
(See full trace by running task with --trace)
```
After:
```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:migrate:redo` you must run the namespaced task with a VERSION. Available tasks are db:migrate:redo:primary and db:migrate:redo:secondary.
Tasks: TOP => db:migrate:redo
(See full trace by running task with --trace)
```
Running the namespaced version:
```
» bin/rails db:migrate:redo:secondary
== 20200728162820 CreateAnimals: reverting ====================================
-- drop_table(:animals)
-> 0.0025s
== 20200728162820 CreateAnimals: reverted (0.0047s) ===========================
== 20200728162820 CreateAnimals: migrating ====================================
-- create_table(:animals)
-> 0.0028s
== 20200728162820 CreateAnimals: migrated (0.0029s) ===========================
```
This PR ensures that when you're generating a scaffold or model and that
model should belong to another database it will create an abstract class
if it doesn't already exist.
The new abstract class will ensure that the new model inherits from that
class, but will not be deleted if the scaffold is deleted. This is
because Rails can't know if you have other models inheriting from that
class so we don't want to revoke that if the scaffold is destroyed.
If the abstract class already exists it won't be created twice. If the
options for `parent` are set, the generator will use that as the
abstract class instead of creating one. The generated abstract class
will add the writing connection automatically, users need to add the
reading connection themselves as Rails doesn't know which is the reading
connection.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
The `config/application.rb` file of a plugin test dummy app should be
the same as in a standard Rails app, with the exception of an additional
`require` statement to load the plugin itself. However, prior to this
commit, the plugin generator used a specialized template for a portion
of this file, which tended to drift out-of-sync with the standard app
generator's template. Specifically, this drift could result in missing
`require` statements of newer Rails frameworks when the plugin generator
was run with any `--skip-xxxx` option.
This commit changes the plugin generator to insert its additional
`require` statement into the standard `config/application.rb` file
generated by the app generator.
Engines are not applications, indeed 'Application < Engine', so it's the other way round.
The difference can be confusing anyway, so we should make sure the documentation is clear.
When passing a camelcased model name to a generator sometimes it's
impossible to inflect the casing. For example "BFF" will generate a
route for the controller BffsController, but the controller generated is
BfFsController.
The casing is impossible to inflect if both:
- a camelcased model name is passed to a generator
- `name.pluralize.underscore.singularize != name.underscore.singularize`
If this happens we raise an error. The error message explains the user
can either us an underscored name or add an inflection instead.
308 status code introduced in https://tools.ietf.org/html/rfc7538
preserves the request method unlike 301 status code which would convert
POST requests to GET.
This change swaps the CommonJS require() syntax in the Webpacker
application.js pack template file and in documentation examples with ES
module import syntax.
Benefits of this change include:
Provides continuity with the larger frontend community: Arguably, one of
the main draws in adopting Webpacker is its integration with Babel to
support ES module syntax. For a fresh Rails install with Webpacker, the
application.js file will be the first impression most Rails developers
have with webpack and Webpacker. Most of the recent documentation and
examples they will find online for using other libraries will be based
on ES module syntax.
Reduces confusion: Developers commonly add ES imports to their
application.js pack, typically by following online examples, which means
mixing require() and import statements in a single file. This leads to
confusion and unnecessary friction about differences between require()
and import.
Embraces browser-friendliness: The ES module syntax forward-looking and
is meant to be supported in browsers. On the other hand, require()
syntax is synchronous by design and not browser-supported as CommonJS
originally was adopted in Node.js for server-side JavaScript. That
webpack supports require() syntax is merely a convenience.
Encourages best practices regarding optimization: webpack can statically
analyze ES modules and "tree-shake", i.e., strip out unused exports from
the final build (given certain conditions are met, including
`sideEffects: false` designation in package.json).
If an assertion is inside a method stub, it may never be evaluated.
This is particularly problematic when asserting a method is called a
non-zero number of times.
This commit moves such assertions outside their method stubs.
Follow up to c07dff72278fb7f2a3c4c71212a0773a2b25c790.
Actually it is not the cop's fault, but we mistakenly use `^`, `$`, and
`\Z` in much places, the cop doesn't correct those conservatively.
I've checked all those usage and replaced all safe ones.
Silence Rake task backtraces, similar to Rails::BacktraceCleaner.
Application lines are preserved, but all other lines are hidden.
This also affects unrecognized tasks, causing the backtrace to be hidden
entirely. Closes#39524.
Co-authored-by: Petrik <petrik@deheus.net>
This test was incorrect. `primary` was winning for the schema cache load
but when you boot an application it's actually the first configuration
that wins (in a multi db app).
The test didn't catch this because I forgot to add a migrations_paths to
the configuration.
We updated the schema cache loader railtie as well because any
application that didn't have a `primary` config would not be able to use
the schema cache. Originally we thought we'd enforce a `primary`
configuration but no longer feel that's correct. It's simpler to say
that the first wins in a 3-tier rather than implementing a solution to
require `primary` and / or allow aliases.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Co-authored-by: John Hawthorn <john@hawthorn.email>
Applications may not have a primary configuration so we should not
assume there is one. In both these cases we can get the right connection
without that.
For the databases.rake file we want to re-establish a connection for the
environment we're in. The first config defined under an environment for
a multi-db app will win. This is already the case on application boot so
we should be consistent.
For the info.rb file we already have a connection so we can lookup the
adapter from the connection's db_config. If a primary hadn't existed
this would have thrown an exception.
Followup to https://github.com/rails/rails/pull/39535 which removed the
assumption there was a primary config from the schema cache load
railtie.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Generators generate things, but what is meant by 'Stubbing out' might
confuse beginners and non-native English speakers.
While generated tests are stubs that should have an implementation, a
generated model is a valid model that doesn't require any changes.
details_cache_key already references Template::Types.symbols and view
resolvers cache based on default_formats and other values. This
previously wasn't an issue because no views had been looked up before
this was set. Now that we are building a regex from the values of
Template::Types.symbols we need to clear cache after changing this
setting.
Errors *should* output their stack. Somehow these tests were passing
before. This clarifies all states (skip/fail/error) and works against
@tenderlove's patch.
Before #39304 was merged, backtraces would look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 22205
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007f9ce19b9620>
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:522:in `ensure in process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:542:in `process'
/Users/aaron/git/rails/actionpack/lib/action_controller/test_case.rb:395:in `get'
test/controller/request_forgery_protection_test.rb:1005:in `test_ignores_trailing_slash_during_generation'
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.213230s, 4.6898 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
After #39304 was merged they look like this:
```
$ be ruby -I lib:test test/controller/request_forgery_protection_test.rb -n test_ignores_trailing_slash_during_generation
Run options: -n test_ignores_trailing_slash_during_generation --seed 62892
E
Error:
PerFormTokensControllerTest#test_ignores_trailing_slash_during_generation:
NoMethodError: undefined method `have_cookie_jar?' for #<Object:0x00007fa6d60193c8>
rails test test/controller/request_forgery_protection_test.rb:1004
Finished in 0.211953s, 4.7180 runs/s, 0.0000 assertions/s.
1 runs, 0 assertions, 0 failures, 1 errors, 0 skips
```
This patch reverts the part of #39304 that removes the backtrace.
- Add the configuration option for annotating templates with file names to the generated app.
- Add `annotate_rendered_view_with_filenames` option to configuring guide.
* Add default ENV variable option with BACKTRACE to turn off backtrace cleaning when debugging framework code
* Use runner as the example
Although I think we should consider dropping -b in tests and just relying on this more general option for sidestepping the backtrace cleaner.
I'm not sure about this one. The gist is, minitest's
UnexpectedError#message includes a backtrace but the reporter tests
here expect there not to be one in inline output.
Personally, I think that's wrong as it removes information you'd want
to debug, but this might be a philosophical difference with the rails
test ethos... or it might just be aesthetic.
I am happy to back out this change and fix the tests if you'd rather.
This reverts commit 0f9249c93f402d276730fcfaba1ed1b876ee7c26.
Reverted because this wasn't warning in custom jobs and therefore
applications may have not seen the deprecation. We'll need to fix the
deprecation to warn for custom jobs so that applications can migrate.
* Adds a rails test:all rake task
This task runs all tests, including system tests.
* Better placement + slight tweak of the comment
Co-authored-by: David Heinemeier Hansson <david@loudthinking.com>
Register a callback that will get called right after generators has
finished.
This is useful if users want to process generated files.
For example, can execute an autocorrect of RuboCop for generated files
as like following.
```ruby
config.generators.after_generate do |files|
system("bundle exec rubocop --auto-correct " + files.join(" "), exception: true)
end
```
This makes test file patterns configurable via two environment variables:
`DEFAULT_TEST`, to configure files to test, and `DEFAULT_TEST_EXCLUDE`,
to configure files to exclude from testing.
These values were hardcoded before, which made it difficult to add
new categories of tests that should not be executed by default (e.g:
smoke tests).
It uses environment variables instead of regular Rails config options
because Rails environment is not available when the Runner builds the
list of files to test (unless using Spring). A nicer solution would be
making sure that the Rails environment is always loaded when the runner
starts. This is a first simple step to make these paths configurable for
now
This way at least you could override defaults in `config/boot.rb`:
```ruby
ENV["DEFAULT_TEST_EXCLUDE"] = "test/{dummy,smoke,system}/**/*_test.rb
```
Co-authored-by: Jeremy Daer <jeremydaer@gmail.com>
In the past, we sometimes hit missing `Symbol#start_with?` and
`Symbol#end_with?`.
63256bc5d7a8e812964d
So I proposed `Symbol#start_with?` and `Symbol#end_with?` to allow duck
typing that methods for String and Symbol, then now it is available in
Ruby 2.7.
https://bugs.ruby-lang.org/issues/16348
Using `String#starts_with?` and `String#ends_with?` could not be gained
that conveniency, so it is preferable to not use these in the future.
Rake stores the current top-level task and arguments in global state.
Invoking another top-level task within the same process requires
overwriting this state. Doing so indiscriminately can cause incorrect
behavior, such as infinitely repeating the original task. In
particular, this is a problem when running one task from another via
`rails_command "...", inline: true`.
The solution is to save and restore the global state in each call to
`RakeCommand.perform` using the `Rake.with_application` method.
Fixes#39128.
37913 added the possibility to deeply merge configurations by grouping
them within a shared section. This powerful alternative was not reflected
in any documentation, which made my team think it was not possible until
I found out this feature after looking at the source code.
This patch reflects this change in the documentation so that it is
easier for other developers to know about this behavior.
