| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
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.
|
|\
| |
| | |
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.
|
|\ \
| |/
|/| |
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.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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:
|
|\
| |
| | |
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.
|
|/
|
|
|
|
|
|
| |
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
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
Add example so its easier to understand how one can overide
an app generator.
|
|\
| |
| |
| |
| | |
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.
|
| | |
|
|\ \
| | |
| | | |
Add wrapper for plugin's test runner
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently, private API is directly used in `bin/test`. It is necessary to change
`bin/test` when changing private API.
To avoid this, provide a wrapper file and modify `bin/test` to just require that
file.
|
| | | |
|
| | | |
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Simplify the version specifier generated by prereleases
|
| | |
| | |
| | |
| | |
| | | |
"~> 1.2.3.pre4" will automatically allow "1.2.4" -- no need for an
explicit range.
|
| | | |
|
| | |
| | |
| | |
| | | |
(#28093)
|
|\ \ \
| | | |
| | | | |
Use Puma 3.7
|
| | |/
| |/|
| | |
| | | |
ref this commit seems that has not been merged into 3.7 https://github.com/puma/puma/commit/42bec4600c51ab8a1c1ee5a0e1b738a4ffd82bf2
|
|\ \ \
| | | |
| | | | |
WIP: Capybara Integration with Rails (AKA System Tests)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This renames the system test helper file to be application system test
case to match what the rest of Rails does. In the future we should
consider changing the test_helper to match.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Override integration test default host
Integration tests automatically set the default host to
'http://example.com'. This works fine for integration tests because they
are not real browser sessions, but doesn't work fine for system tests
because they are real browser sessions.
We can override this by setting the `host!` in `before_setup. The
`Capybara.always_include_port` will allow the test to look at
`127.0.0.1:port capybara picks` and properly redirect the test.
Any application can override this by setting the `host!` in
their system test helper. Generally though, applications are going to be
using localhost.
In this commit I also moved the setup and teardown into their own module
for tidiness.
* Move teardown settings into system test case
These configuration options can be put into the system test case file
instead of the generated system tests helper file. This is an
implementation detail and therefore shouldn't be generated with the
template.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
This serves as self documentation so users know how to change the
driver.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* 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
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Originally I had set up system testing to have one configuration option
to be set in the test environment. After thinking it over I think a
generated class on app creation would be best. The reason for this is
Capybara has a ton of configuration options that I'm sure some folks
want to use.
Thinking about how we handle screenshots, database transactions, and a
whole bunch of other settings it would be better for users to be able to
turn all of that on and off.
When an app or scaffold is generated a `test/system_test_helper.rb` test
helper will be generated as well. This will contain the class for tests
to inherit from `ActionSystemTestCase` which will inherit from
`ActionSystemTest::Base`. Here is where users can change the test
driver, remove the screenshot helper, and add their additional Capybara
configuration.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | |
| | | |
| | | |
| | | | |
Rubocop / code climate don't like single quotes and prefer doubles.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* Generates system test requirements with new Rails app
* Includes required default gems in Gemfile for Rails app
* Generates a single system test case
* Generates a system test case with scaffold
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
y-yagi/prevent_multiple_values_being_set_to_run_via
Prevent multiple values being set to `run_via`
|
| | | |
| | | |
| | | |
| | | |
| | | | |
When executing the test via rake, since `rake` is set for `run_via`, `ruby` should not be set.
Related 2cb6c27310452da11b93d729c3b760ce988106e1
|
|\ \ \ \
| | | | |
| | | | | |
Do not run `git init` in dummy application
|
| | |/ /
| |/| | |
|
|/ / /
| | |
| | |
| | | |
refs: #28011
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
mtsmfm/fix-generator-command-for-nested-rails-engine-take-2
Fix generator command for nested (namespaced) rails engine (take 2)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Rewrite https://github.com/rails/rails/pull/27550
085546df45 was reverted (b6ffb5efcb) because it change the return of `namespaced_path` from String to Array.
----------------
If we create nested (namespaced) rails engine such like bukkits-admin,
`bin/rails g scaffold User name:string age:integer`
will create
`bukkits-admin/app/controllers/bukkits/users_controller.rb`
but it should create
`bukkits-admin/app/controllers/bukkits/admin/users_controller.rb`.
In #6643, we changed `namespaced_path` as root path
because we supposed application_controller is always in root
but nested rails engine's application_controller will not.
|