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.
Previously, a test runner argument had to contain a forward slash to be
recognized as a path. Now, backslashes will also be considered,
enabling the use of Windows-style paths.
Fixes#38243.
Mandrill's Inbound API checks to see if a URL exists before it creates
the webhook. It sends a HEAD request, to which we now return a 200 OK
response to indicate that the route exists.
Now we can generate inbound API calls with ease on Mandrill, without
having to shuffle around tokens in production.
Fixes#37609.
`url_for` will now use "https://" as the default protocol when
`Rails.application.config.force_ssl` is set to true.
Action Mailer already behaves this way, effectively. This commit
extends that behavior application-wide.
Closes#23543.
These were removed in 74201c3885ae2e33bfff046d503324fd1d7a320f when the
template for the 6.0 new framework defaults initializer was deleted.
While we no longer generate the file, upgrading applications will still
have it, so it's still important to check that these options can be set.
I introduced this pattern of referencing a constant to trigger lazy load
hooks in 458a5502a17ccf58d5708a3b030ac9917a0a8476, and it arrived at its
current form via c98a641ff402d3ca5b754f4621a0764f33eab155 and
c24be369322b9e0211fcef30003375de195ef660.
I now realise autoloading doesn't need to be involved at all; we can
require the files that trigger the lazy load hooks directly.
* Add a way to deliver inbound emails by source
Great for testing when you get an eml file and can just paste it in.
* Test updates
* Fix tests
* Fix spacing
* require, require_relative, load by double quotes
We're getting rid of all single quote usage, unless it serves a specific purpose, as per the general style guide.
The `rails test` command scans its arguments for test paths to load
before handing off option parsing to Minitest. To avoid incorrectly
interpreting a `-n /regex/` pattern as an absolute path to a directory,
it skips arguments that end with a slash. However a relative path ending
in a slash is not ambiguous, so we can safely treat those as test paths.
This is especially useful in bash, where tab completing a directory
leaves a trailing slash in place.
With a multiple database application `db:rollback` becomes problematic.
We can't rollback just the primary, that doesn't match the behavior in
the other tasks. We can't rollback a migration for every database, that
is unexpected.
To solve this I handled `db:rollback` the same way I handled `:up` and
`:down`. If `db:rollback` is called for a multi-db application then it
will raise an error recommending you use `db:rollback:[NAME]` instead.
Calling `db:rollback:primary` or `db:rollback:animals` will rollback
the migration for the number of steps specified.
Closes: #38513
Follow-up to: #34078
This method was jumping through extra hoops to find the name of the
class the connection is stored on when we can get it from the connection
itself. Since we already have the connection we don't need to loop through the
pools.
In addition, this was using the wrong class name. The class name for the
schema migration should come from the connection owner class, not from
the `db_config.name`. In this case, `db_config.name` is the name of the
configuration in the database.yml. Rails uses the class name to lookup
connections, not the db config name, so we should be consistent here.
While working on this I noticed that we were generating an extra schema
migration class for `ActiveRecord::Base`. Since `ActiveRecord::Base` can
and should use the default and we don't want to create a new one for
single db applications, we should skip creating this if the spec name is
`ActiveRecord::Base`. I added an additional test that ensures the class
generation is correct.
If I had had these tests previously I would have not created PR #38658
and then promptly realize I needed to revert it.
We need to load and parse the configurations twice. Once before the
environment is loaded to create the named tasks and once after the
environment is loaded to have the real configurations. The configs
loaded before the env have the ERB stripped out and aren't valid
configs.
I have so. many. regrets. about using `spec_name` for database
configurations and now I'm finally putting this mistake to an end.
Back when I started multi-db work I assumed that eventually
`connection_specification_name` (sometimes called `spec_name`) and
`spec_name` for configurations would one day be the same thing. After
2 years I no longer believe they will ever be the same thing.
This PR deprecates `spec_name` on database configurations in favor of
`name`. It's the same behavior, just a better name, or at least a
less confusing name.
`connection_specification_name` refers to the parent class name (ie
ActiveRecord::Base, AnimalsBase, etc) that holds the connection for it's
models. In some places like ConnectionHandler it shortens this to
`spec_name`, hence the major confusion.
Recently I've been working with some new folks on database stuff and
connection management and realize how confusing it was to explain that
`db_config.spec_name` was not `spec_name` and
`connection_specification_name`. Worse than that one is a symbole while
the other is a class name. This was made even more complicated by the
fact that `ActiveRecord::Base` used `primary` as the
`connection_specification_name` until #38190.
After spending 2 years with connection management I don't believe that
we can ever use the symbols from the database configs as a way to
connect the database without the class name being _somewhere_ because
a db_config does not know who it's owner class is until it's been
connected and a model has no idea what db_config belongs to it until
it's connected. The model is the only way to tie a primary/writer config
to a replica/reader config. This could change in the future but I don't
see value in adding a class name to the db_configs before connection or
telling a model what config belongs to it before connection. That would
probably break a lot of application assumptions. If we do ever end up in
that world, we can use name, because tbh `spec_name` and
`connection_specification_name` were always confusing to me.
Follow-up to #38463.
By isolating ARGV, we guard against commands inadvertently depending on
prior ARGV contents. Any such command will now behave consistently when
run via `Rails::Command.invoke`, whether coming from the Rails CLI or
from library code. Likewise, any ARGV mutations done by a command will
not affect code that executes after `Rails::Command.invoke`.
A .ruby-version file is not useful in a plugin dummy app because the
plugin itself dictates the required Ruby version. Indeed, the dummy app
.ruby-version file might fall out of sync with whatever the plugin
dictates, and thus result in unexpected "Could not find gem" errors when
running commands from within the dummy app directory.
When is use a scaffold_controller add the routes as resources to the
config/route.rb
Also enable to use --skip-routes if doesn't want include the resources
into the config/routes.rb file.
The schema cache tests test the following scenarios:
1) The default case works (single db, primary spec name (dev is default
to primary in 2-tier config), standard default schema cache filename)
2) Primary always wins over other entries
3) A custom schema cache filename works when set in the configuration
4) A custom schema cache filename works when set in the ENV
Cases that don't work:
1) A non-primary database entry picks up a namespaced schema cache file
This can't work currently because there's no way of knowing which cache
we actually want. In this railtie we can only load ActiveRecord::Base's
schema cache. If we grab the first config we risk loading a cache for
another connection because order is not guaranteed.
2) Multi-db schema caches
The reasons are similar to above. In addition we can't loop through the
configs, establish a connection, and load the cache because we don't
know what parent class to establish a connection to. In that case AR
Base will always get the cache and it would cause the last one to win
and therefore be loaded on the wrong connection.
The real fix for these issues is to get rid of the railtie entirely, but
for now we needed to set this back to what the behavior was before
recent changes but with the ability to pass a custom key.
Co-authored-by: Katrina Owen <kytrinyx@github.com>
When generating applications, it initializes Git repository since
8989a5057b
However, it doesn't initialize Git when creating plugins.
Plugins are mostly libraries and are likely hosted on GitHub,
so initializing Git for plugins makes sense.
The initializer that loads the default schema cache on the default
connection doesn't account for the case where an app overrides the
default filename either via ENV["SCHEMA_PATH"], or via the
:schema_cache_path defined in the db config.
Note that as discussed in #34449 this initializer doesn't work for
applications using multiple databases, and this change doesn't fix that.
Introduce benchmark generator to add benchmarks to Rails applications.
The generator makes use of `benchmark-ips`, and will automatically add
the gem to the Gemfile as needed.
Co-authored-by: Gannon McGibbon <gannon.mcgibbon@gmail.com>
