皆さんは、パッケージやフレームワークのアップデートに追われていたりしないでしょうか?
特に業務では、事業上や法務上の対応など、アップデート以外にも多数行うことがあり、残念ながらEOLギリギリで対応、もしくは超過してしまっていることも多いのではないかと思います。そこで、個人的にはできれば常日頃から少しずつアップデートに向けたコストを払うことで、最後の最後に溜まった負債を返すのではなく、先々から少しずつ払うようにしていきたいと思っていました。
そうした中で、Timeeさんの以下の取り組みを知りました。
これをまずはシンプルなGitHub Actionsでとりあえず失敗するテストがないかのチェックだけでもやってみようと思い、試してみました。
リポジトリ
リポジトリは以下です。サンプルプロジェクトのため、実際にはテストなどもなく、CIの動作検証のみとなっています。
Rails edge(RailsのGitHubリポジトリのmainブランチ)を bundle install する
まずは通常の開発に影響が出ない形で、Rails edge のCIでのみ、Rails edgeが適用されるようにします。そのため、CIで利用するGemfileを用意します。
# frozen_string_literal: true # 既存のGemifleを読み込んでから、Railsをmainブランチにする eval_gemfile File.expand_path('../Gemfile', __dir__) dependencies.delete_if { |d| d.name == 'rails' } gem 'rails', branch: 'main', github: 'rails/rails'
このGemfile を利用するために、 bundle install する際には、 環境変数 BUNDLE_GEMFILE
に gemfiles/rails_edge.gemfile
を指定しておきます。
# ... 省略 ... env: BUNDLE_GEMFILE: gemfiles/rails_edge.gemfile # ... 省略 ...
GitHub Actionsの設定ファイルを作成する
あとはRSpecを実行するGitHub Actionsの設定ファイルを作成します。
name: Test rails edge on: workflow_dispatch: # 定期実行の場合は以下を設定する # schedule: # - cron: '0 * * * *' env: BUNDLE_GEMFILE: gemfiles/rails_edge.gemfile RAILS_ENV: test TZ: 'Asia/Tokyo' jobs: build: name: build runs-on: ubuntu-latest services: mysql: # ... 略 ... steps: - name: Checkout from Repository uses: actions/checkout@v2 with: ref: main - name: Setup Ruby version uses: actions/setup-ruby@v1 with: ruby-version: 3.1.x - name: bundle install run: | bundle install --jobs 4 --retry 3 - name: Setup Database run: | bundle exec rake db:create bundle exec rake db:migrate - name: RSpec run: bundle exec rspec
まとめ
比較的簡単に、Railsでバージョンアップした際にテストがどうなるか検証するためのCIを作成できました。
Timeeさんの元の記事では、きちんと失敗したテストをpendingにして管理しているので、こうした仕組み化も含めてできると良さそうですね。