For better or worse, the Rails guide settled on double quotes
and a large part of the community also use rubocop which enforce
them by default.
So we might as well try to follow that style when providing code
snippets in the documentation or error messages.
Fix: https://github.com/rails/rails/issues/49822
I certainly didn't get them all, but consistency should be significantly
improved.
This patch adds support for automatically getting OTP codes from your
YubiKey during release. You must have the `ykman` commandline tool
installed, and have two accounts setup with the names `rubygems.org` and
`npmjs.com`. For example, the output from `ykman oath accounts list` on
my machine is this:
```
$ ykman oath accounts list
npmjs.com:aaron.patterson@gmail.com
rubygems.org:aaron.patterson@gmail.com
```
If you meet these conditions, you can do `rake release` without typing
an OTP code for every gem.
If no `ykman` tool is found on your system, this will just fall back to
asking for an OTP code.
Allows the releaser to verify that:
- A rich text description can be edited and shown *richly*.
- An image/PDF can be uploaded and generate a variant that's shown.
Also moves the generated app to a tmp directory for less cleanup need.
The Frameworks collection was missing actiontext and actionmailbox,
this would mean they are skipped when running any tasks that
iterated through this collection
changes include
Breaking up frameworks declaration into multiple lines and put
them in order. This should make adding to the list easier and
if you need to scan it, they will be in order you would expect
Add `package` task to both actiontext and actionmailbox
- Layout/TrailingWhitespace
```
actionpack/lib/action_controller/metal/request_forgery_protection.rb:49:4:
C: Layout/TrailingWhitespace: Trailing whitespace detected.
#
^
```
Related to c3787494ed
- Performance/StartWith
```
tasks/release.rb:108:44: C: Performance/StartWith:
Use String#start_with? instead of a regex match anchored to the beginning of the string.
header += "* No changes.\n\n\n" if current_contents =~ /\A##/
```
I saw these ones while working on #32362.
File.write was introduced in Ruby 1.9.3 and it is the most concise way
to perform bulk writes (as File.read is for bulk reading).
The existing flags enabled binmode, but we are dumping text here.
The portable way to dump text is text mode. The only difference is
newlines, and portable code should in particular emit portable newlines.
Please note the hard-coded \ns are still correct. In languages with C
semantics for newlines like Ruby, Python, Perl, and others, "\n" is a
portable newline. Both when writing and when reading. On Windows, the
I/O layer is responsible for prepending a CR before each LF on writing,
and removing CRs followed by LFs on reading. On Unix, binmode is a
no-op.
### Summary
In a Rails application using Ruby 2.6.0-dev, when running `bin/rails g migration`
with `RUBYOPT=-w`, an ERB deprecation warnings will be displayed.
```console
% ruby -v
ruby 2.6.0dev (2018-03-03 trunk 62644) [x86_64-darwin17]
% bin/rails -v
Rails 6.0.0.alpha
% RUBYOPT=-w bin/rails g migration create_foos
(snip)
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing safe_level with the 2nd argument of ERB.new is
deprecated. Do not use it, and specify other arguments as keyword
arguments.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing trim_mode with the 3rd argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, trim_mode: ...)
instead.
/Users/koic/src/github.com/rails/rails/railties/lib/rails/generators/migration.rb:66:
warning: Passing eoutvar with the 4th argument of ERB.new is
deprecated. Use keyword argument like ERB.new(str, eoutvar: ...)
instead.
create db/migrate/20180304002144_create_foos.rb
```
This PR suppresses the above deprecation warnings in Ruby 2.6.0-dev.
This warning is due to the interface of `ERB.new` will change from Ruby 2.6.
> Add :trim_mode and :eoutvar keyword arguments to ERB.new.
> Now non-keyword arguments other than first one are softly deprecated
> and will be removed when Ruby 2.5 becomes EOL. [Feature #14256]
2311087b68/NEWS (stdlib-updates-outstanding-ones-only)
The following addresses are related Ruby's commit.
https://github.com/ruby/ruby/commit/cc777d0
Also this PR will change `ERB.new` used in `tasks/release.rb`.
### Other Information
This PR uses `ERB.version` to switch `ERB.new` interface. Because Rails 6
supports multiple Ruby versions (Ruby 2.4.1 or higher), it need to
use the appropriate interface.
Using `ERB.version` instead of `RUBY_VERSON` is based on the following patch.
https://github.com/ruby/ruby/pull/1826
This patch is built into Ruby.
40db89c093
Basically revises the release flow to:
* Update the version in RAILS_VERSION + rake changelog:header
* Run rake all:verify (click around in the booted app)
* If that checks out, run rake release.
Note: this commit looks super weird becuase git. I'm moving the entire
NPM section to the part where we actually push the gems/npm package for
the reasons below. That's not how the git diff looks though.
When we release Rails we run `rake prep_release` which calls
`update_versions`. This was updating the NPM version as well. But when we
would later run `rake install` to test the installed gem
`update_versions` gets called again which causes the install to fail
because NPM sees the version is the same as the last run and refuses to
continue. If you forget to stash this will then cause the push to
RubyGems to fail because `update_versions` is called again and then NPM
will not continue because it thinks the version hasn't been changed even
though it has.
The correct solution would be to not update the NPM verion if it matches
the version already in the file but after an hour I could not find a
simple way to use NPM to read the current version. Honestly that's not
the best way to do it either because say you forget to update something
else and then the script thinks it's already been updated.
With that in mind I think the best solution is to not update the NPM
version until right before we are going to push to NPM because then that
won't cause the push to RubyGems to fail.
Rafael Mendonça França