| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
| |
since this is a new change, many will be coming here to toggle the true/false config and not find it. This will allow them to quickly implement the change.
|
|\
| |
| | |
List options for `rails new --webpack=WEBPACK`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When you type `rails new -h`, the `--database=DATABASE` options display
this useful message:
> Preconfigure for selected database (options: mysql/postgresql/sqlite3/oracle/frontbase/ibm_db/sqlserver/jdbcmysql/jdbcsqlite3/jdbcpostgresql/jdbc)
However, the `--webpack=WEBPACK` option only displays this:
> Preconfigure for app-like JavaScript with Webpack
so it's hard to know *which* values are valid for `WEBPACK`.
This commit improves the help message to display:
> Preconfigure for app-like JavaScript with Webpack (options: react/vue/angular)
The implication of this commit is that the list needs to be manually updated
whenever rails/webpacker adds support for a new framework.
However, I don't imagine this list to change very frequently, and I think that
the benefit of display the list to the users is greater than the hustle of
updating the list when needed.
|
|\ \
| | |
| | | |
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.
|
|\ \ \ \
| |_|_|/
|/| | | |
Don't add a dummy API key to every new Rails app
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Every new Rails app is currently generated with
`Rails.application.secrets[:api_key]` set to `123`.
This comes from a line in `config/secrets.yml` that, in my opinion,
should be left commented out to only serve as a syntax example, rather
than being actually set in every Rails app.
Additionally, we might want to give a better example than `123`, since
in the same file we are suggesting to
> Make sure the secret is at least 30 characters and all random,
> no regular words or you'll be exposed to dictionary attacks.
The result of this commit is that `config/secrets.yml` will include something like:
```yaml
# Shared secrets are available across all environments.
# shared:
# api_key: f56930851993982510d5bd9236f4108f6fe7c15448f1c6923a51872e0dbae1a24d274b318abb6518b540dfb51079c61640885f607467e5ed1053849be7587d61
```
rather than this:
```yaml
# Shared secrets are available across all environments.
shared:
api_key: 123
```
|
|/ /
| |
| |
| |
| |
| |
| | |
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 😋
|
|\
| |
| |
| |
| | |
chukitow/feature/user-form-with-instead-of-form-for-scaffold
user form with instead of form for in scaffold generator
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Capybara was updated in teamcapybara/capybara#1841 to use Minitest style
assertions so that system test output shows x number of assertions, x
numbe of failures, etc.
Before:
```
6 runs, 0 assertions, 0 failures, 0 errors, 0 skips
```
After:
```
6 runs, 7 assertions, 1 failures, 0 errors, 0 skips
```
This change bumps Capybara from 2.7.0 to 2.13.0 and includes the
required minitest assertion file in the test case. :tada:
|
|/
|
|
|
| |
Instead of calling methods of Rails.application directly, we need to
use a method that is considered for the rails engine.
|
|\
| |
| | |
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.
|
| |
| |
| |
| |
| |
| | |
Mostly just that it's there.
Closes #28193.
|
|\ \
| | |
| | | |
Update `database.yml` when `rails new <new_app> -d oracle` specified
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Install "activerecord-oracle_enhanced-adapter".
Oracle adapter used to be a bundled one. Now it is a 3rd party one.
Also "ruby-oci8" is a required gem for CRuby, not for JRuby.
- Remove oracle entry for JRuby since Oracle enhanced adapter
supports both CRuby and JRuby with single gem.
- Change adapter name from `oracle` to `oracle_enhanced` in the oracle.yml.
Not changing `-d oracle`
- Update `DATABASE_URL` entry to use a dash instead of an underscore
Refer https://github.com/rails/rails/commit/d72a0cbc807a14d3eec02a53317d11b9d9fa5815
for the reason.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
So calling `filename_with_extensions` omitting the second argument like this
https://github.com/slim-template/slim-rails/blob/8dbc1fbf859ebfa95b0884a0196a6ad9f0ca9cd5/lib/generators/slim/scaffold/scaffold_generator.rb#L10
causes NoMethodError.
fixes #28275
|
|/ /
| |
| |
| |
| |
| |
| | |
It turns out that we don't need to require system tests in the railties
test helper so we can remove it. If you're using system tests they will
be loaded by inheriting from ActionDispatch::SystemTestCase and the
routes will be loaded by ActionDispatch::IntegrationTest.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Update secrets to use modern crypto
|
| | |
| | |
| | |
| | | |
Fixes #28135.
|
| | |
| | |
| | |
| | |
| | |
| | | |
In order to avoid `NoMethodError` when it is nil.
Follow up to 82f7dc6178f86e5e2dd82f9e528475a6acee6cd8
|
| | |
| | |
| | |
| | | |
Prefer Thor's say method to Kernel's plain puts.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
y-yagi/use_appropriate_type_for_test_framework_option
Use appropriate type for `test_framework` option
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This fixes the following warning.
```
Expected string default value for '--test-framework'; got false (boolean)
```
|
|\ \ \ \
| | | | |
| | | | | |
`HOST` must be all capital letters
|
| |/ / /
| | | |
| | | |
| | | | |
Ref: https://github.com/rails/rails/blob/master/railties/lib/rails/commands/server/server_command.rb#L194
|
|/ / /
| | |
| | |
| | |
| | | |
When `rails new plugin` is invoked, turbolinks should be skipped in the dummy
test application generated by the plugin generator.
|
| | |
| | |
| | |
| | | |
Because webpacker 1.0 already released.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
y-yagi/set_correct_host_except_development_environment
Set correct host except development environment
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
|\ \ \
| |/ /
|/| |
| | |
| | | |
y-yagi/only_load_systemtestcase_if_puma_is_defined
Only load SystemTestCase if Puma is defined
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
SystemTestCase supports only Puma, and always load puma's file.
https://github.com/rails/rails/blob/master/actionpack/lib/action_dispatch/system_testing/server.rb#L1
For that reason, the case of use Capybara but do not use Puma, it will cause an error.
So we need to check about Puma is defined as well.
|
| | |
| | |
| | |
| | |
| | | |
Add example so its easier to understand how one can overide
an app generator.
|
|\ \ \
| |/ /
|/| | |
[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
|