| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/ |
|
|
|
|
|
|
|
|
| |
on sprockets environment
- Remove jquery-rails if --skip-sprockets is true
Fixes #23431
|
|
|
|
|
|
|
|
| |
Redis now included in Gemfile but commented out. This change was made in
91864439c7aebb6ca710831aac6781903a433904 and is causing the test
failure.
See https://travis-ci.org/rails/rails/jobs/106994913#L1025
|
|\
| |
| | |
move `test_generator_if_skip_action_cable_is_given_for_an_api_app` to the appropriate file
|
| |
| |
| |
| |
| |
| | |
appropriate file
Test of Rails API should be in `api_app_generator_test.rb`.
|
|/
|
|
|
|
| |
Generated engines should call `protect_from_forgery`. If this method
isn't called, then the Engine could be susceptible to XSS attacks.
Thanks @tomekr for reporting this to us!
|
|\
| |
| | |
Add Default Puma Config
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When the `puma` command is run without any configuration options it will detect presence of a `config/puma.rb` file and use that. Currently there is discrepancy between `puma` command and `rails server` but Evan said it would be reasonable to add in reading in config from the default location. I am working on that right now as a feature in puma/puma.
Why do we need this? By default Puma uses 16 threads, and by default ActiveRecord only has 5 threads. Due to the architecture of AR it is guaranteed that if you're running with fewer DB connections than your server has threads you will hit `ActiveRecord::ConnectionTimeoutError ` eventually if your app gets modest amounts of traffic. Since we are providing a default webserver, we should provide reasonable configuration for that webserver.
This PR does a few things, first it sets the default Puma thread count to 5 to mach ActiveRecord's default. It sets the default environment to `"development"` and the default port to 300 so that booting the server with `$ puma` will give you the same default port as `rails server`. It is worth mentioning that by reading in from `PORT` environment variable this config can work with containerized deployments, such as on Heroku.
We are not using worker processes by default, that way JRuby and windows devs can use this configuration without modification. I went ahead and included a default `on_worker_boot`. It won't be used unless a worker count is specified, that means this config will not use it. Even though it's not being used now It will make someone who wants to try modifying their config to run extra workers easier.
cc/ @pixeltrix
|
|\ \
| | |
| | | |
Redis sans EventMachine
|
| | |
| | |
| | |
| | |
| | |
| | | |
This new adapter does get a little more intimate with the redis-rb gem's
implementation than I would like, but it's the least bad of the
approaches I've come up with.
|
|/ / |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- Using `references` or `belongs_to` in migrations will always add index
for the referenced column by default, without adding `index:true` option
to generated migration file.
- Users can opt out of this by passing `index: false`.
- Legacy migrations won't be affected by this change. They will continue
to run as they were before.
- Fixes #18146
|
| |
| |
| |
| |
| |
| | |
as argument
- Fixes #23137.
|
|/ |
|
|
|
|
|
| |
Because the form is not in the Rails API,
`per_form_csrf_tokens` initializer I think unnecessary.
|
|\
| |
| | |
Remove action_cable_meta_tag when skip Action Cable
|
| | |
|
|/ |
|
|\
| |
| |
| |
| | |
y-yagi/add_application_mailer_rb_to_mountable_engine
add application_mailer.rb to template of mountable engine
|
| | |
|
| |
| |
| |
| |
| | |
since 9446e38ba47c9ca3be2ad668d8a8bea0141be6fc, generated mailer inherents from ApplicationMailer,
ApplicationMailer is required in the mountable engine.
|
|\ \
| | |
| | |
| | | |
Adapterize storage for ActionCable
|
| | | |
|
| |/ |
|
|/
|
|
| |
Forgot to remove it, when I changed the expectations in 88881d2.
|
| |
|
| |
|
|
|
|
| |
It was removed by mistake at 877a411d0c16baa4e670dae9a28f5cfcc201adc1
|
|
|
|
|
| |
`rack-cors` gem is defined in Gemfile by default only if the api,
not defined by default in rails app.
|
|\
| |
| | |
Ensure Action Cable files are removed when `skip_action_cable` is set.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The Action Cable generators creates four files which need to be removed
if `skip_action_cable` is set.
1. `app/assets/javascripts/cable.coffee`
2. `app/channels/application_cable/channel.rb`
3. `app/channels/application_cable/connection.rb`
4. `config/redis/cable.yml`
Fixes #22669.
|
| | |
|
|\ \
| | |
| | | |
Ensure that assets are enabled back after the test that tests assets are disabled
|
| | |
| | |
| | |
| | | |
disabled
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
teknofire/fix-using-add_resource-with-a-block-after-gem-call
Fix using add_resource with a block after gem in custom generators
|
| |/
| |
| |
| | |
generator template.
|
|\ \
| | |
| | | |
Action Cable channel generator doesn't create JS assets if options[:rails][:assets] is false
|
| |/ |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The errors message only was not displayed, as if it did not use the inline reporting,
modified to also information the method name and the like in error are displayed.
```
# before
Failed assertion, no message given.
bin/rails test test/models/user_test.rb:5
```
```
# after
Failure:
UserTest#test_the_truth:
Failed assertion, no message given.
bin/rails test test/models/user_test.rb:5
```
|
|
|
|
|
| |
Our logic is complex now and we don't need to check the version to asset
the behavior so I'm removing the checking here.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We originally chose to apply very strict versioning on the `rails` entry
in the Gemfile, because our future versioning policy was not strongly
defined.
Now it is, and our policy is very much designed on the expectation that
people will regularly update to the latest patch level in their release
series... so we should encourage that.
Of course, Gemfile.lock will do its job and prevent unplanned updates,
just as it does for every other gem in the bundle... but if you run
`bundle update`, we want to get you the latest bug/security fixes
without requiring a manual edit of the Gemfile entry.
Our current version could be a few different shapes, so it takes a bit
of work to find the right specifier, but in principle, we match anything
of the form x.y.*, where x.y matches our current release series.
|
|
|
|
| |
Application* parent
|
|
|
|
| |
I think Markdown is nowadays a better default.
|
| |
|
| |
|
| |
|
|\ |
|
| |\
| | |
| | | |
Introduce ApplicationRecord, an Active Record layer supertype
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|