| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
| | | |
|
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| | |
Would have caught that the invoke changes broke rake delegation
behavior.
And we do ship the behavior so we should test it.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Simplify the version specifier generated by prereleases
|
| | |
| | |
| | |
| | |
| | | |
"~> 1.2.3.pre4" will automatically allow "1.2.4" -- no need for an
explicit range.
|
|\ \ \
| | | |
| | | | |
Implement custom url helpers and polymorphic mapping
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Use a separate method called `resolve` for the custom polymorphic
mapping to clarify the API.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Using `undef_method` means that when a route is removed any other
implementations of that method in the ancestor chain are inaccessible
so instead use `remove_method` which restores access to the ancestor.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow the use of `direct` to specify custom mappings for polymorphic_url, e.g:
resource :basket
direct(class: "Basket") { [:basket] }
This will then generate the following:
>> link_to "Basket", @basket
=> <a href="/basket">Basket</a>
More importantly it will generate the correct url when used with `form_for`.
Fixes #1769.
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Allow the definition of custom url helpers that will be available
automatically wherever standard url helpers are available. The
current solution is to create helper methods in ApplicationHelper
or some other helper module and this isn't a great solution since
the url helper module can be called directly or included in another
class which doesn't include the normal helper modules.
Reference #22512.
|
|/ / /
| | |
| | |
| | | |
(#28093)
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
```
Minitest.run_via[:rails] = true
```
👆 would break because a simple alias won't catch the second
true argument there.
|
|\ \ \
| | | |
| | | | |
Use Puma 3.7
|
| | |/
| |/|
| | |
| | | |
ref this commit seems that has not been merged into 3.7 https://github.com/puma/puma/commit/42bec4600c51ab8a1c1ee5a0e1b738a4ffd82bf2
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Move system tests back into Action Pack
* Rename `ActionSystemTest` to `ActionDispatch::SystemTestCase`
* Remove private base module and only make file for public
`SystemTestCase` class, name private module `SystemTesting`
* Rename `ActionSystemTestCase` to `ApplicationSystemTestCase`
* Update corresponding documentation and guides
* Delete old `ActionSystemTest` files
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Renames `Rails::SystemTestCase` to `ActionSystemTest` and moves it to a
gem under the Rails name.
We need to name the class `ActionSystemTestCase` because the gem expects
a module but tests themselves expect a class.
Adds MIT-LICENSE, CHANGELOG, and README for the future.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
* Adds test case test
* Adds driver adapter test
* Adds tests for capybara seleium driver (testing the settings not
actually opening the browser to test capybara w/ selenium because that
would so so so slow)
* Adds tests for rack test driver
* Adds tests for generators
|
|\ \ \
| | | |
| | | | |
Do not run `git init` in dummy application
|
| |/ / |
|
|/ / |
|