Ruby

Rails 8.0におけるpublic_file_server.headersの設定の変更

rails newで生成されるconfig/environments/test.rbと同development.rbにおいて、 このプルリクエストのマージによって、 config.public_file_server.headersのキーが以下のように小文字になりました。

-    config.public_file_server.headers = { "Cache-Control" => "public, max-age=#{2.days.to_i}" }
+    config.public_file_server.headers = { "cache-control" => "public, max-age=#{2.days.to_i}" }

変更された理由はRack 3への対応のためですので、既存アプリでも設定を変更するのが良さそうです。

Rails 8.0におけるdeprecation関連の設定の削除

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

  # Raise exceptions for disallowed deprecations.
  config.active_support.disallowed_deprecation = :raise

  # Tell Active Support which deprecation messages to disallow.
  config.active_support.disallowed_deprecation_warnings = []

削除された理由は、当該プルリクエストによると、アプリが新規生成された直後は非推奨の問題と無縁であるということからのようです。 ですので、非推奨の問題が出てくる可能性のある既存アプリにおいては適切な設定をしたままにしておくのが良さそうです。

Rails 8.0ではfilter_parametersに:cvvと:cvcが追加された

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

セキュリティの観点からは、確かにクレジットカードのCVCとCVVをフィルタすることは適切であるように思いますので、既存アプリにおいても:cvvと:cvcを追加すると良さそうです。

Rails 8.0への移行における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

詳しくは、「Rails 7.1への移行におけるActive Storageのmigration」のコメントをご覧ください。

不要であればアイコン画像の削除

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

• icon.png
• icon.svg

より詳細な情報はrails 7.2への移行におけるアイコン画像のコメントをご覧ください。

基本的にはRailsガイドの手順に従えば良いと思います。

ガイドの手順にもありますが、ぜひbin/rails app:updateコマンドを活用しましょう。

rails 8.0への移行で対応が必要そうな個別の作業について、以下のコメントでそれぞれ取り上げますので、ご参考になれば幸いです。

bundle binstubs brakemanを用いるやり方に更新しました。

rails 7.2では、新規アプリに対してデフォルトでGitHubワークフローの設定ファイルであるci.ymlが生成されるようになりました。そこで、このci.ymlの内容について簡単に解説します。

なお、ci.ymlの最新のテンプレートはこちらでご覧になれます。

scan_ruby

bin/brakemanコマンドを実行するジョブです。 Railsの一般的なセキュリティ脆弱性がないかどうかチェックします。

scan_js

bin/importmap auditコマンドを実行するジョブです。 利用しているJavaScriptパッケージにセキュリティ上の脆弱性がないかどうかチェックします。

lint

bin/rubocopコマンドを実行するジョブです。 Rubyの静的コード解析を行い設定されているルールに準拠しているかどうかチェックします。

test

bin/rails testコマンドを実行するジョブです。なお、skip_system_testオプションが無効であれば、システムテストも実行します。

Rails 7.2においてDev Container設定を生成する機能が追加されました。 例えば既存アプリでは、以下のコマンドで既存アプリ用のDev Container設定を生成できるようになりました。

rails devcontainer

生成した設定は、Visual Studio Codeで利用でき、Dev Containerを利用した既存アプリの開発が可能となります。 必要となるソフトウェアのインストール等、Dev Containerでの開発を開始するための手順についてはDev Containerでの開発ガイドが参考になります。

なお、Visual Studio Code以外のエディタでもDev Containerで開発できるようにするべくDev Container CLIというツールの開発が進んでいますが、2024年12月現在では、ポートフォワーディングに対応していないなど、今のところはまだまだ開発途中のツールであり、実開発に投入するにはまだ早い段階である印象です。

Rails 7.2からRuboCopが新規アプリケーションでデフォルトで有効になりました。 このTopicでは、7.1以前で作成した既存RailsアプリにRuboCopを後から導入して、RuboCopに関して7.2の新規アプリ相当の状態にセットアップする方法をご紹介します。

RuboCop (Omakase Ruby styling for Rails) のインストール

基本的にはrubocop-rails-omakaseの公式ドキュメントのインストール手順に従います。

まず以下のように、Gemfileのgroup :development, :testのところにrubocop-rails-omakaseを追加します。

group :development, :test do

  # Omakase Ruby styling [https://github.com/rails/rubocop-rails-omakase/]
  gem "rubocop-rails-omakase", require: false

end

次にbundle installを実行して、RuboCop等をインストールします。

bundle install

さらに、必須ではありませんが、bin/rubocopでRuboCopを実行できるように、以下のコマンドを実行します。

bundle binstubs rubocop

最後に.rubocop.ymlという名前でファイルを作成し、以下の内容を記述します。

# Omakase Ruby styling for Rails
inherit_gem:
  rubocop-rails-omakase: rubocop.yml

以上でRuboCop (Omakase Ruby styling for Rails) のセットアップが出来ました。

ローカル環境でのbin/rubocopの実行とその結果に対する対応の進め方

以下のコマンドでbin/rubocopを実行でき、omakaseのチェックを行えます。

bin/rubocop

このチェックでの指摘事項が多かった場合、以下のオプションを付けて実行することで、 無視設定を記述した.rubocop_todo.ymlというファイルが作成され、 .rubocop.ymlにもこの無視ファイルを参照する設定が追加されますので、 とりあえず全ての指摘事項を無視するように設定が出来ます。

bin/rubocop --auto-gen-config

設定が出来たら、bin/rubocopを実行して、とりあえず指摘事項の数が0となることを確認します。

1つずつ指摘事項へ対応

ここから先は、以下の手順を繰り返します。

• .rubocop_todo.ymlから1項目を削除
• bin/rubocopを実行して指摘内容を確認して対応
  • bin/rubocop -aもしくはbin/rubocop -Aを実行して自動修正できるものは自動修正し、その修正内容で問題ないことを確認
    • -aは安全なもののみ、-Aは安全で無いものも含めて自動修正を行います。
  • 自動修正できなかったものは手作業で修正・確認
  • 特定のファイルのみチェックを回避する場合は、.rubocop.ymlにてExclude:を用いて設定
  • ソースコードの特定の箇所（行）のみチェックを回避する場合は、ソースファイルのコメントに# rubocop:disable等を用いて設定
  • 指摘内容に対応する規則を完全に採用しない場合には、.rubocop.ymlにてEnabled: falseの記述を用いて規則を無効にする

1項目ずつ対応を進め、.rubocop_todo.ymlの中身が無くなったら、.rubocop_todo.ymlを削除すると共に、.rubocop.yml内で.rubocop_todo.ymlを参照している設定を削除します。ここまで終わればRuboCopの諸規則への対応は完了となります。お疲れ様でした。

GitHubワークフロー（CI）でのrubocopの実行

.github/workflows/ci.ymlに相当するファイルがなければ作成します。 この.ymlファイルを編集して、以下のようにjobsの下にlintジョブを追加します。

注意点

• timeout-minutes:の設定は、実行時間に対して十分余裕を持たせて下さい。
• ruby-version: .ruby-versionという設定は、プロジェクトルートにある.ruby-versionという名前のファイルで指定されているrubyのバージョンという意味になります。この設定について詳しくはこちらのTopicをご覧下さい。
• -f githubオプションは、出力フォーマットをGitHub Actionsに適したものにするオプションです。

jobs:
  lint:
    runs-on: ubuntu-latest
    timeout-minutes: 10

    steps:
      - name: Checkout code
        uses: actions/checkout@v4

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

      - name: Lint code for consistent style
        run: bin/rubocop -f github

公式情報

• RuboCopのその他の詳細についてはRuboCop公式ドキュメントをご覧ください。
• Omakase Ruby styling for RailsのRuboCop設定の最新の内容はGitHubで確認出来ます。なお、最新ではなくインストールしたバージョンのRuboCop設定内容をご覧になりたい場合は、GitHubの操作でTagsから当該バージョンを選択するようにして下さい。