rubyの標準添付ライブラリであるuriに存在しているURI::MailTo::EMAIL_REGEXPは、 ある文字列が規格上Emailアドレスとして適切かどうかのチェックに以下のように利用できます。

irb(main):001> require 'uri'
=> true
irb(main):002> URI::MailTo::EMAIL_REGEXP
=> /\A[a-zA-Z0-9.!\#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*\z/
irb(main):003> URI::MailTo::EMAIL_REGEXP.match?('[email protected]')
=> true
irb(main):004> URI::MailTo::EMAIL_REGEXP.match?('[email protected]')
=> false
irb(main):005> URI::MailTo::EMAIL_REGEXP.match?('[email protected]')
=> false

Railsガイドでも、 このEMAIL_REGEXPを用いてemailのバリデーションを行う方法を以下のように紹介しています。

validates :email, format: { with: URI::MailTo::EMAIL_REGEXP }

URI::MailTo::EMAIL_REGEXPを使うメリット

TechRachoの記事によると、URI::MailTo::EMAIL_REGEXPの正規表現はHTML規格書から持ってきているため、 URI::MailTo::EMAIL_REGEXPを使ったバリデーションはブラウザがinput type="email"で行うバリデーションと一致するというメリットがあります。

余談

URI::MailTo::EMAIL_REGEXPは、 Rubyリファレンスマニュアルにも Ruby標準ライブラリリファレンスにも、実は記載されていません。 ですので、URI::MailTo::EMAIL_REGEXPを利用するのは少々裏技的な側面があるのかもしれません。 ただ、上述の通り、Railsガイドや記事で取り上げられるぐらいに認知されていますので、利用しても大丈夫なのではないかと思います。

GitHub Actionsの設定ファイルでsetup-rubyを使う時に、 以下のようにruby-versionのところで.ruby-versionと指定すると、 GitHubレポジトリからチェックアウトされたプロジェクトの中にある .ruby-versionという名前のファイルで指定されているrubyのバージョンが GitHub Actionsのsetup-rubyで使われます。

      - name: Set up Ruby
        uses: ruby/setup-ruby@v1
        with:
          ruby-version: .ruby-version
          bundler-cache: true

jobsが複数あって、同じバージョンで複数回setup-rubyをしているときなどには、バージョン記述の重複がなくなって有用だと思います。

（参考）

この指定方法は、railsの新規アプリのGitHub Actionsの設定で利用されています。

A comment by @test_withdrawn

rails 7.2への移行におけるアイコン画像

bin/rails app:updateコマンドを実行すると以下の2つのアイコン画像ファイルがpublic/に作成されますが、
これら2つのファイルは、rails newで生成される新規railsアプリ用のファイルであるため、既存アプリでは単純に削除してしまい、 従来通りのアイコン画像とアイコン設定（faviconやapple-touch-icon）を用いれば大丈夫です。 （もちろん、既存アプリにおいてアイコン設定が適切に行われている場合の話です。）

• icon.png
• icon.svg

ちなみに、以下の通りrails 7.2では、新規アプリのアイコン設定が大幅に更新されています。 rails 7.2のこの新たなアイコン設定は、既存アプリにおいてもアイコン設定を見直す際に役立つかもしません。

（参考）rails 7.2.1の新規アプリのアイコン設定

以下が、新規アプリ用のテンプレートファイルからコピーしたrails 7.2.1の新規アプリのアイコン設定です。

    <link rel="manifest" href="/manifest.json">
    <link rel="icon" href="/icon.png" type="image/png">
    <link rel="icon" href="/icon.svg" type="image/svg+xml">
    <link rel="apple-touch-icon" href="/icon.png">

新たなアイコン画像ファイルによるアイコン設定に関与しているプルリクエストは、 PR #50526と PR #50629です。 3つのアイコン画像ファイル（apple-touch-icon-precomposed.png、apple-touch-icon.png、favicon.ico）が削除され、 2つのアイコン画像ファイル（icon.png、icon.svg）が追加されています。 また、manifestに関しては、PWAに関する新機能に関連して導入されています。

rails 7.2ではassertionがないテストに対して警告が出るようになった

現象

rails 7.2では、Minitestを使ったテストに関して、assert系メソッドが1つも呼ばれないテストがあると"Test is missing assertions"という警告が出るようになりました。

警告が出ないようにする方法

各テストでassert系メソッドが最低1回は実際に呼ばれるようにして下さい。 例外が起きないことを確認するテストではassert_nothing_raisedメソッドを用いて下さい。 なお、警告の回避方法を含め、こちらの記事が参考になるかもしれません。

関連するプルリクエストとコミット

この機能はPR #51625で導入され、このときはrailsアプリの設定によって挙動を変えられるようになっていました。 その後、commit 6a6c7e6によって機能が単純化され、単に常に警告が出力されるだけになりました。 その後、PR #51693で関係するコードを綺麗にする作業などが行われています。

rails 7.2で追加されたブラウザバージョン指定機能と406-unsupported-browser.html

bin/rails app:updateコマンドを実行するとpublic/に406-unsupported-browser.html作成されます。 このHTMLフィアルは、rails 7.2で追加されたブラウザバージョン指定機能が指定範囲外のブラウザに対して送るファイルです。

なお、既存アプリでは、この機能の利用を始めないのであれば、念のため406-unsupported-browser.htmlを置くだけ置いておくという対応で良いように思います。

rails 7.2への移行におけるActive Storageのmigration

bin/rails app:updateコマンドを実行すると以下の3つのファイルがdb/migrate/に作成されることがありますが、
Active Storageをまだ使用したことがないアプリケーションでは、 これら3つのファイルは単純に削除してしまっても良いはずです。

• xxx_add_service_name_to_active_storage_blobs.active_storage.rb
• xxx_create_active_storage_variant_records.active_storage.rb
• xxx_remove_not_null_on_active_storage_blobs_checksum.active_storage.rb

より正確に言うと、データベースにactive_storage_blobsテーブルが存在していない場合は、 これら3つのファイルは単純に削除してしまっても良いはずです。 その理由として、これら3つのファイルはデータベースのactive_storage_blobsテーブルに対して影響を与えるものであり、 table_exists?(:active_storage_blobs)がfalseを返すと何もせずにreturnする処理が3つのファイル全てに記述されているからです。

ご自身のRailsアプリケーションのデータベースにactive_storage_blobsテーブルが存在するかの確認はbin/rails consoleを実行して、 以下のようにコマンドを実行することで行えます。 結果がfalseであればactive_storage_blobsテーブルは存在していない、つまり前述の3つのファイルは削除で大丈夫のはずです。

foobar(dev)> ActiveRecord::Base.connection.table_exists? :active_storage_blobs
=> false

ちなみに、データベースにあるテーブルの一覧を見たい場合にはbin/rails consoleで ActiveRecord::Base.connection.tablesを叩くことでテーブルの一覧を確認できます。

rails 7.2でのconfig/puma.rbの大幅な更新

rails newで生成されるconfig/puma.rbが大幅に更新されました。

• v7.1.4のpuma.rb.tt
• v7.2.1のpuma.rb.tt

主要な変更点は以下の通りです。

• threadsの指定方法の変更: リリースノート：Pumaのデフォルトのスレッド数が新しくなった、PR #50450 、PR #50669
• pidfileの変更: PR #50644、PR #50669、commit 57a6916
• environmentの削除: PR #52541
• production環境でのworkersの削除: commit 142e6ab
• production環境でのpreload_app!の削除: PR #52541
• development環境でのworker_timeoutの削除: PR #52541

rails 7.2ではfilter_parametersに:emailが追加された

rails newで生成されるconfig/initializers/filter_parameter_logging.rbにおいて、 rails 7.2でconfig.filter_parametersに:emailが追加されました。 この追加に関するプルリクエストはこちらです。

 Rails.application.config.filter_parameters += [
-  :passw, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn
+  :passw, :email, :secret, :token, :_key, :crypt, :salt, :certificate, :otp, :ssn
 ]

セキュリティや個人情報保護の観点からは、確かにメールアドレスをフィルタすることは適切であるように思いますので、既存アプリにおいても:emailを追加すると良さそうです。

ちなみに、デバッグ作業などでメールアドレスを確認するときには少し不便になるような気もしますが、 emailへの直接の読み書きが疎外されるわけではありませんし、 またpluckなどの活用もすればデバッグの支障にはさほどならないような気がします。

rails 7.2におけるpublic_file_server.enabled

rails newで生成されるconfig/environments/test.rbにおいて、 7.1以前は以下の設定用コードが存在していましたが、 このプルリクエストのマージによって削除されました。

  config.public_file_server.enabled = true

削除された理由は、このプルリクエストによると、default値がtrue、かつ、全てのenvironment（test、development、production）の間で設定値に違いが無いということからです。 ですので、既存アプリにおいても、設定値をtrueとしている場合には、この設定用コードは削除してしまっても良いかもしれません。