| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| | |
Plugin Usage and Installation instructions
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Didn't like the constant being at the top of the file, gave it overdue importance.
Now that `color_output` expects a result we can shorten some of the flexibility
from earlier:
* Inline COLOR_CODES constant (keep local variable for readability,
but don't need names of colors at run time).
* Inline color variable in `color_output`. Looks just as clear without it.
|
| |
| |
| |
| |
| | |
Focus `color_output`'s intent on coloring output by a result. We aren't meant
to pass it arbitrary codes to color output.
|
| |
| |
| |
| |
| |
| | |
The word color is being thrown all around with slightly different meanings.
Right now, I understand it. But I'd like to be more immediately clear.
|
| |
| |
| |
| | |
I got the blues because we aren't coloring any lines blue.
|
| |
| |
| |
| |
| |
| |
| | |
The static red color wouldn't paint skips in their designated yellow.
Use the color name we got from the result label earlier, which marks
skips as yellow.
|
| |
| |
| |
| |
| |
| |
| |
| | |
I should have replaced the summary reporter with a subclass
the first time I wrote this.
For whatever reason, I didn't. Do it right and slim the methods added
to Minitest in the process.
|
| |
| |
| |
| |
| |
| | |
Minitest by default includes a summary reporter and a progress reporter.
To print colored output, we have to replace the progress reporter.
|
|\ \
| | |
| | | |
Add colored output to the new test reporter.
|
| | | |
|
|\ \ \
| | | |
| | | | |
seeds.rb.tt: fix English.
|
| | | | |
|
|\ \ \ \
| |/ / /
|/| | | |
remove cors initializer from rails app
|
| | | |
| | | |
| | | |
| | | |
| | | | |
`rack-cors` gem is defined in Gemfile by default only if the api,
not defined by default in rails app.
|
|/ / /
| | |
| | |
| | | |
[ci skip]
|
|\ \ \
| |_|/
|/| | |
Fix .keep file issue with ActionCable
|
| | |
| | |
| | |
| | |
| | |
| | | |
Fixes #22708
Make sure the channels file is create in assets/javascript/ so require
tree works in asset pipeline.
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| |
| | |
[ci skip]
The old link is 404 not found.
The link matches what the rest of the documentation already points to:
* https://github.com/rails/rails/blame/2de2263118d6763c11a02db05079a5b7a97a0a34/guides/source/getting_started.md#L2052
* https://github.com/rails/rails/blame/2de2263118d6763c11a02db05079a5b7a97a0a34/README.md#L74
|
|\ \
| | |
| | | |
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
|
| |/ / |
|
|\ \ \
| | | |
| | | | |
display detailed information in inline reporting
|
| | |/
| |/|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
```
|
|\ \ \
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
```
Every time when a fixture generate, it’s also generating improper doc.
one: {}
# column: value
#
two: {}
# column: value
```
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
gwincr11/No-Doc-Rails__Generators__Actions__CreateMigration
Add No Doc
|
| | | |
| | | |
| | | |
| | | | |
In reference to rails/rail#22403 add a :nodoc:
|
|\ \ \ \
| | | | |
| | | | | |
Remove blank line generated in config.ru
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Follow the lines of the other `.tt` files ([example](https://github.com/rails/rails/blob/1611ab4db173a7596a7a94c58dabf1483f070304/railties/lib/rails/generators/rails/app/templates/config/environments/development.rb.tt#L26)) that have the space after the
condition to avoid too many white lines in the resulted file.
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
In line with the other initializers, add a short comment that explains
what happens when you change the value of the initializer.
[ci skip]
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | | |
[ci skip]
The initializer has existed since 4.1, for instance see:
https://github.com/rails/rails/blob/v4.1.0/railties/lib/rails/generators/rails/app/templates/config/initializers/cookies_serializer.rb
|
| | | |
|
| | |
| | |
| | |
| | | |
:tada: :beers:
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| | | |
| | | |
| | | | |
Allow normal version updates within a release series
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | |
| | |
| | |
| | | |
Still more to do. Please assist!
|
| | | |
|
| | | |
|
| | | |
|