| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
|\ \
| | |
| | | |
Clear active connections after initialization
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Any connections that were checked out during initialization should be
checked back in before the first request is processed, for two reasons:
- Returning the connection to the pool allows it to be health checked
before it's used again. If the connection dies before the first
request arrives, the health check will replace it with a new one.
- If the thread that initialized Rails is not the same thread that will
be performing work, checking in the connection will allow it to be
reused instead of being stuck to the initialization thread forever.
|
|\ \ \
| | | |
| | | | |
Raise when using a bad symlink
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There was a case where a dev made a symlink that worked on some machines and not on others. The issue manifested itself on a machine with `RAILS_ENV=staging` as the had their `config/environments/staging.rb` symlinked to another config file. The behavior was very hard to track down.
Current behavior: If you use a bad symlink in a file, you get no warnings or failures or anything. If you have a bad symlink it just ignores the file as if it didn't exist (`File.exist?` returns false for a bad symlink).
Patch behavior: With this patch when a file is not present we check if a symlink exists. If it does, that indicates there is a bad symlink and we should raise
```
File "config/environments/staging.rb" is a symlink that does not point to a valid file
```
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
With Rack::Test the headers needs to match the `HTTP_` format. The tests
were passing before because they are not asserting the response was a
cache hit.
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
y-yagi/remove_unnecessary_files_to_api_applications_when_app_task_task_executed
Remove unnecessary files to API-only Applications when `app:task` task executed
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | |
| | | | | | |
Remove -j (--javascript) option from `rails new`
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The "-j" option was added 5 years ago (https://github.com/rails/rails/commit/d9c39c3a)
when we wanted to support prototype-rails and jquery-rails.
Prototype is not as popular and jQuery is not a requirement anymore.
Still the "-j" option can be used to install *any* gem that ends in "-rails".
This "might" open security issues and does not bring great benefits anymore.
If you know which "-rails"-ending gem you want to install, you can manually
add it to the Gemfile just like any other gem.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
fix migrate with empty version
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Add stronger assertions to rake migration tasks to make sure the user is providing a numeric VERSION
An empty string was getting converted to version = 0. This would in turn pass the presence check.
Address linting warning
Add test for rake task and refactor code to meet expectations
In particular passing VERSION=0 should not raise an error.
Addressed Comments for PR #28485. Trimmed empty lines + change of wording for error message
Adjust test for change of wording in error message
Change condition to follow rails idioms
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
y-yagi/do_not_display_hidden_namespaces_in_destroy_command_help
Do not show hidden namespaces in destroy commnad help
|
| |/ / / / / |
|
|\ \ \ \ \ \
| |/ / / / /
|/| | | | | |
ignore system test gems on Gemfile when execute with --skip-test option
|
| |/ / / / |
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | | |
This is a follow up to a6d065e. When using `form_with` you must supply
field ids manually. Since the scaffold generator is using labels we
need to make sure that they are linked up properly.
|
|\ \ \ \
| | | | |
| | | | | |
Correctly reset ARGV for "rails runner `CODE' arg arg arg..."
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The code itself should not be in the ARGV vector.
Fixes #28515
|
|\ \ \ \ \
| | | | | |
| | | | | | |
CLI arg "host" has precedence over ENV var "host"
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is a regression from when the server command switched to its own
argument parser, as opposed to Rack's. Rack's argument parser, when
provided with a "host" argument, gives that value precedence over
environment variables.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is necessary only when updating to Rails 5.0, it is not necessary
for updating to 5.1.
Related #24243
|
| | | |
| | | |
| | | |
| | | | |
More intention revealing and means `f` can go F itself 😋
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Occasionally we update the file generated by engine.
Therefore, I think that there is a task for updating as well as
application in the engine, it is convenient for updating.
|
|\ \ \ \
| | | | |
| | | | | |
Fix `warning: character class has duplicated range`
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This fixes the following warnings:
```
railties/test/generators/encrypted_secrets_generator_test.rb:15: warning: character class has duplicated range: /[\w\d]+/
railties/test/generators/encrypted_secrets_generator_test.rb:18: warning: character class has duplicated range: /production:\n# external_api_key: [\w\d]+/
railties/test/generators/encrypted_secrets_generator_test.rb:19: warning: character class has duplicated range: /production:\n# external_api_key: [\w\d]+/
```
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It can not check correctly with `defined?`
```ruby
irb(main):001:0> Rails.application.config.active_record
=> {:maintain_test_schema=>true, :belongs_to_required_by_default=>true}
irb(main):002:0> defined?(Rails.application.config.active_record)
=> nil
```
Follow up to #28469
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of forcing new applications to carry an initializer that just
switches things to what their default "should" be, we can handle it
internally.
The initializer is then only used by upgraders: it shows what the new
default would be (commented out), while their upgraded application
continues to operate as it did before.
Under this model, a multiply-upgraded application could accumulate
several new_framework_defaults_*.rb files, for each release series it
has traversed. A given release series only needs to generate the latest,
though, because we don't support `rails app:upgrade` while skipping
releases.
|
|\ \ \ \
| | | | |
| | | | | |
Add secrets edit test
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Make destroy command work within engines
|
| |/ / / /
| | | | |
| | | | |
| | | | |
| | | | | |
Instead of calling methods of Rails.application directly, we need to
use a method that is considered for the rails engine.
|
|/ / / /
| | | |
| | | |
| | | |
| | | | |
`rails:update` was changed to `app:update` in 6fb31638c8b61731103d4963272755b217a2df87.
Therefore, I think that it is better that the test name is also `app_update`.
|
|\ \ \ \
| | | | |
| | | | | |
Show correct commands in help
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Currently rails' help shows only namespace. However, the secrets command
needs to specify command. Therefore, I fixed the command to display in help.
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes the following thor's warning.
```
Expected string default value for '--generate'; got false (boolean)
```
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
These tests may be expansive so let's only allow users to run them
through `bin/rails test:system` or by passing a path to the `test`
command.
The same applies for `bin/rake test`.
Refs #28109.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
If application has ajax, browser may begin request after rollback.
`teardown_fixtures` will be called after `super` on `after_teardown`
so we must call `Capybara.reset_sessions!` before `super`
https://github.com/rails/rails/blob/b61a56541aecd7ac685d4f19d943177a3f1b465a/activerecord/lib/active_record/fixtures.rb#L857
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Update secrets to use modern crypto
|
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes #28135.
|
| |_|_|/
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In case there's no $EDITOR assigned users would see a cryptic:
```
% EDITOR= bin/rails secrets:edit
Waiting for secrets file to be saved. Abort with Ctrl-C.
sh: /var/folders/wd/xnncwqp96rj0v1y2nms64mq80000gn/T/secrets.yml.enc: Permission denied
New secrets encrypted and saved.
```
That error is misleading, so give a hint in this easily detectable case.
Fixes #28143.
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently `localhost` is used for the default host in all environments.
But up to Rails 5.0, `0.0.0.0` is used except for development.
So fixed to use the same value as 5.0.
Fixes #28184
|
|\ \ \
| | | |
| | | | |
[close #24435] Send user_supplied_options to server
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently when Puma gets a `:Port` it doesn't know if it is Rails' default port or if it is one that is specified by a user. Because of this it assumes that the port passed in is always a user defined port and therefor 3000 always "wins" even if you specify `port` inside of the `config/puma.rb` file when booting your server with `rails s`.
The fix is to record the options that are explicitly passed in from the user and pass those to the Puma server (or all servers really). Puma then has enough information to know when `:Port` is the default and when it is user defined. I went ahead and did this for all values rails server exposes as server side options for completeness.
The hardest thing was converting the input say `-p` or `--port` into the appropriate "name", in this case `Port`. There may be a more straightforward way to do this with Thor, but I'm not an expert here.
Move logic for parsing user options to method
Better variable name for iteration
Explicitly test `--port` user input
✂️
Update array if environment variables are used
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
y-yagi/do_not_display_hidden_namespaces_in_generators_help
does not show hidden namespaces in generator's help
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
y-yagi/make_adding_gemfile_entry_work_even_if_specify_only_the_plugin_name
Make adding gemfile entry work even if specify only the plugin name
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Whether the command was executed within the rails application is checked
by whether or not the application's path matches `app_path`.
https://github.com/rails/rails/blob/5-0-stable/railties/lib/rails/generators/rails/plugin/plugin_generator.rb#L439..L441
Therefore, if only plugin name is specified in `app_path`, addition to
Gemfile is not done.
However, in the rails guide an example of specifying only plugin name
is given, and it is considered that there are many cases where only
plugin name is specified.
For that reason, made it work even if only plugin name was specified.
|