Previously, we used the migration status to determine whether the test
database(s) needed to be reloaded from the schema. This worked in most
cases, but if a schema.rb was modified outside of migrations or if a
migration was rolled back, it would require a manual db:test:prepare.
This commit updates load_schema to record the SHA1 of the loaded schema
file inside of the ar_internal_metadata table. We can then use this SHA
to determine whether we should reload the schema.
This ensures that the test DB stays exactly in sync with the schema
file, including rollbacks which fixes a test marked TODO.
The `rake db:seed` command was broken for the primary environment if the
application is using multiple databases. We never implemented `rake
db:seed` for other databases (coming soon), but that shouldn't break the
default case.
The reason this was broken was because `abort_if_pending_migrations`
would loop through the configs for all databases and check for
migrations but would leave the last established connection. So `db:seed`
was looking in the wrong database for the table to seed.
This PR doesn't fix the fact that `db:seed` doesn't work for multiple
databases but does fix the default case.
Fixes#36817
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Applications are not supposed to use require_dependency in their own
code if running in zeitwerk mode, and require_dependency was initially
aliased to require with that use case in mind.
However, there are situations in which you cannot control the mode and
need to be compatible with both. There, you might need require_dependency
in case you are being executed in classic mode. Think about engines that
want to support both modes in their parent applications, for example.
Furthermore, Rails itself loads helpers using require_dependency.
Therefore, we need better compatibility.
* read config/webpacker.yml to determine which path to exclude for zeitwerk:check
* fix test errors
* more changes to fix test errors
* refactor webpacker_path
[Andrew Kress + Rafael Mendonça França]
- I made a change in https://github.com/rails/rails/pull/36691 to
delegate route helper to a proxy class.
This didn't take into account that the `url_options` we redefine
in SystemTest would be ignored.
This PR fixes that by definin the url_options inside the proxy
A HTTP feature policy is Yet Another HTTP header for instructing the
browser about which features the application intends to make use of and
to lock down access to others. This is a new security mechanism that
ensures that should an application become compromised or a third party
attempts an unexpected action, the browser will override it and maintain
the intended UX.
WICG specification: https://wicg.github.io/feature-policy/
The end result is a HTTP header that looks like the following:
```
Feature-Policy: geolocation 'none'; autoplay https://example.com
```
This will prevent the browser from using geolocation and only allow
autoplay on `https://example.com`. Full feature list can be found over
in the WICG repository[1].
As of today Chrome and Safari have public support[2] for this
functionality with Firefox working on support[3] and Edge still pending
acceptance of the suggestion[4].
#### Examples
Using an initializer
```rb
# config/initializers/feature_policy.rb
Rails.application.config.feature_policy do |f|
f.geolocation :none
f.camera :none
f.payment "https://secure.example.com"
f.fullscreen :self
end
```
In a controller
```rb
class SampleController < ApplicationController
def index
feature_policy do |f|
f.geolocation "https://example.com"
end
end
end
```
Some of you might realise that the HTTP feature policy looks pretty
close to that of a Content Security Policy; and you're right. So much so
that I used the Content Security Policy DSL from #31162 as the starting
point for this change.
This change *doesn't* introduce support for defining a feature policy on
an iframe and this has been intentionally done to split the HTTP header
and the HTML element (`iframe`) support. If this is successful, I'll
look to add that on it's own.
Full documentation on HTTP feature policies can be found at
https://wicg.github.io/feature-policy/. Google have also published[5] a
great in-depth write up of this functionality.
[1]: https://github.com/WICG/feature-policy/blob/master/features.md
[2]: https://www.chromestatus.com/feature/5694225681219584
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1390801
[4]: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/33507907-support-feature-policy
[5]: https://developers.google.com/web/updates/2018/06/feature-policy
Until Rails 5.2, generators can run same name multi times without destroying.
But Rails 6.0(with Zeitwerk) can't this. In Rails 6.0, an error occurs
due to class name collision check.
The check uses `const_defined?`, which assumes that the autoload object
is also defined.
https://ruby-doc.org/core-2.6.3/Module.html#method-i-const_defined-3F
It did not work until Rails 5.2, but Zeitwerk seems to be able to
correctly check this against the application's code.
However, this is a little inconvenient if want to run the generator
again like mistake an attribute name(need to run `destoy` before).
In order to solve this, this PR adds an option to skip the collision check.
With this option, you can overwrite files just as did until Rails 5.2.
For multiple databases we attempt to generate the tasks by reading the
database.yml before the Rails application is booted. This means that we
need to strip out ERB since it could be reading Rails configs.
In some cases like https://github.com/rails/rails/issues/36540 the ERB
is too complex and we can't overwrite with the DummyCompilier we used in
https://github.com/rails/rails/pull/35497. For the complex causes we
simply issue a warning that says we couldn't infer the database tasks
from the database.yml.
While working on this I decided to update the code to only load the
database.yml once initially so that we avoid having to issue the same
warning multiple times. Note that this had no performance impact in my
testing and is merely for not having to save the error off somewhere.
Also this feels cleaner.
Note that this will not break running tasks that exist, it will just
mean that tasks for multi-db like `db:create:other_db` will not be
generated. If the database.yml is actually unreadable it will blow up
during normal rake task calls.
Fixes#36540
I changed to set CSP nonce to `style-src` directive in #32932.
But this causes an issue when `unsafe-inline` is specified to `style-src`
(If a nonce is present, a nonce takes precedence over `unsafe-inline`).
So, I fixed to nonce directives configurable. By configure this, users
can make CSP as before.
Fixes#35137.
I changed return value of `ActionDispatch::Response#content_type` in #36034.
But this change seems to an obstacle to upgrading. https://github.com/rails/rails/pull/36034#issuecomment-498795893
Therefore, I restored the behavior of `ActionDispatch::Response#content_type`
to 5.2 and deprecated old behavior. Also, made it possible to control the
behavior with the config.
This PR moves the `schema_migration` to `migration_context` so that we
can access the `schema_migration` per connection.
This does not change behavior of the SchemaMigration if you are using
one database. This also does not change behavior of any public APIs.
`Migrator` is private as is `MigrationContext` so we can change these as
needed.
We now need to pass a `schema_migration` to `Migrator` so that we can
run migrations on the right connection outside the context of a rake
task.
The bugs this fixes were discovered while debugging the issues around
the SchemaCache on initialization with multiple database. It was clear
that `get_all_versions` wouldn't work without these changes outside the
context of a rake task (because in the rake task we establish a
connection and change AR::Base.connection to the db we're running on).
Because the `SchemaCache` relies on the `SchemaMigration` information we
need to make sure we store it per-connection rather than on
ActiveRecord::Base.
[Eileen M. Uchitelle & Aaron Patterson]
When someone has a multi-db application their `ApplicationRecord` will
look like:
```ruby
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
connects_to database: { writing: :primary, reading: :replica }
end
```
This will cause us to open 2 connections to ActiveRecord::Base's
database when we actually only want 1. This is because Rails sees
`ApplicationRecord` and thinks it's a new connection, not the existing
`ActiveRecord::Base` connection because the
`connection_specification_name` is different.
This PR changes `ApplicationRecord` classes to consider themselves the
same as the "primary" connection.
Fixes#36382
Previously, if a test worker exited early, the in-flight test it was
supposed to run wasn't reported as a failure.
If all workers exited immediately, this would be reported as ex.
Finished in 1.708349s, 39.2192 runs/s, 79.0237 assertions/s.
67 runs, 135 assertions, 0 failures, 0 errors, 2 skips
This commit validates that all workers finish running tests by ensuring
that the queue is empty after they exit. This works because we signal
the workers to exit by pushing nil onto the queue, so that there should
be a number of items left in the queue matching potentially missed
tests.
*sigh* this seems like the never ending bug. I don't love or even like
this fix but it does _work_.
Rafael suggested using `dummy_key: dummy_value` but unfortunately
that doesn't work. So we're left with checking whethere there might be
ternary type things in the content and then assuming that we want to
replace the line with a key value pair.
Technically fixes https://github.com/rails/rails/issues/36088
This commit more or less undoes 9b5401f, restores autoloaded? not to
touch the descendants tracker, and autoloaded_constants because it is
documented in the guide.
Previously we were calling the `take_failed_screenshot` method in an
`after_teardown` hook. However, this means that other teardown hooks
have to be executed before we take the screenshot. Since there can be
dynamic updates to the page after the assertion fails and before we
take a screenshot, it seems desirable to minimize that gap as much as
possible. Taking the screenshot in a `before_teardown` rather than an
`after_teardown` helps with that, and has a side benefit of allowing
us to remove the nested `ensure` commented on here:
https://github.com/rails/rails/pull/34411#discussion_r232819478
This change adds the ability to run up/down for a database in a multi-db
environment.
If you have an app with a primary and animals database the following
tasks will be generated:
```
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:up:primary
VERSION=123 rake db:migrate:down:primary
VERSION=123 rake db:migrate:up:animals
```
I didn't generate descriptions with them since we don't generate a
description for a single database application.
In addition to this change I've made it so if your application has
multiple databases Rails will raise if you try to run `up` or `down`
without a namespace. This is because we don't know which DB you want to
run `up` or `down` against unless the app tells us, so it's safer to
just block it and recommend using namespaced versions of up/down
respectively.
The output for the raise looks like:
```
You're using a multiple database application. To use `db:migrate:down`
you must run the namespaced task with a VERSION. Available tasks are
db:migrate:down:primary and db:migrate:down:animals.
```
Currently ActionController::API doesn't include Caching module, so it
can't perform caching. And even if users include it later manually, it
won't inherit application's default cache store for action_controllers.
So the only way to solve this issue is to include Caching module in
ActionController::API, too.
This closes#35602
`bin/setup` and `bin/update` are currently almost the same file. The
only thing that keeps them apart is that one is running `bin/rails
db:setup` and the other `bin/rails db:migrate`.
I'm suggesting here that they should be a unique script, which needs to
be idempotent.
- New to a project, need to get started? `bin/setup`
- Need to install new dependencies that were added recently? `bin/setup`.
Before deprecating `bin/update`, I'm suggesting we just have it call
`bin/setup`.
