銀座Rails#23 July 4, 2020 Yasuo Honda @yahonda 「再現ケース」の必要性とそ の難しさ

● 依存するライブラリやプログラムの変更で、アプリケーションやフレーム ワークに問題が出たときに、どうレポートするか ● Rubyの変更でRailsのCIが落ちたときの例を元にうまくいったこと、うまく いかなかったこと ● 技術的な側面よりも、どのように考えるか、どのように行動するかをお話し します 話すこと

● 開発中のRubyの変更で、開発中のRailsのCIが落ちることがある ○ https://buildkite.com/rails/rails/builds?branch=master ● Ruby 2.8.0dev ○ 1日1回更新される rubylang/ruby:master-nightly-bionic ○ 詳細は How to git bisect ruby/ruby repository 参照 RailsのCI

● Rubyのどのcommitが現象を引き起こしたか特定する ○ git bisect を利用 ○ How to git bisect ruby/ruby repository 参照のこと ● 現象が再現する手順を確立する ○ minitest_bisect を利用する ○ https://gist.github.com/yahonda/b67b19304d34fc1150a9db 79ee325bcc 参照のこと ○ この時点ではRubyにとって”ミニマムな”再現手順ではない ○ "ミニマム"の意味はリポジトリにより異なる Rubyの変更でRailsのCIが落ちたらやること

● 考えられる選択は以下のいずれか ● 現象が発生したRailsのissues ○ Issues · rails/rails · GitHub ● 現象を引き起こした(と報告時点では考えている) Rubyのissues ○ Ruby Issue Tracking System 再現できたらどこにレポートするか

● 現象が発生したレポジトリ ○ 私はずっとこうしていた(Railsのissueとして報告していた) ● いいところ ○ 再現ケースはRailsのUnit testなので、Railsフレームワーク開発者 にとってなじみがある(ミニマムなテストケースといえる) ● よくないところ ○ Rubyの非互換性の可能性があっても、Rails側で「直してしまう」場合 がある 再現できたらどこにレポートするか(2)

● 現象のきっかけとなったレポジトリ ○ いまはこうしています(bugs.ruby-lang.orgにまずレポート) ● いいところ ○ Ruby開発者にRubyの非互換性や問題を直接レポートできる ○ 非互換性や問題はRuby開発者が意図している場合と意図していな い場合があることがわかる ○ Rubyが直る場合とRailsが修正される場合がある ■ 意図しているRubyの非互換性であれば、現象が発生したレポジ トリ(Rails)で修正を行うことになる 再現できたらどこにレポートするか(3)

● よくないところ(難しいところ): ○ ミニマムな再現ケースを作りにくい ○ Ruby開発者にとってはRailsフレームワークのunit testはミニマム ではない ○ Railsのunit testをplainなRubyでの再現ケースにするのは大変 ■ 私自身ほとんどできていない ● Note: 100%の再現性を特定できていない場合 ○ 現象が発生したレポジトリで、再現性を高めるための情報を得ましょ う 再現できたらどこにレポートするか(4)

実際の例2つ

● 最初はRailsにレポートした ○ Action Text and Action View unit tests are failing with ruby 2.8.0dev · Issue #38613 · rails/rails ■ NoMethodError: undefined method `runnables' for ActiveJob::Base:Class ● 2日後にRubyにレポートした ○ https://bugs.ruby-lang.org/issues/16669 Case 1

● よかったこと ○ Rubyが修正された ■ https://github.com/ruby/ruby/commit/8119bcbf ■ https://ruby-trunk-changes.hatenablog.com/entry/rub y_trunk_changes_20200423 に解説があります ● “defined? で undef したメソッドも "method" になってし まっていた” ○ あたらしいRubyのビルドのきっかけになった ■ 後で話します Case 1 (2)

● うまくいかなかったこと ○ bin/testでは再現し、bundle exec rubyでは再現しない違いに気 づいていたが、Ruby(Without Rails)で再現ケースを作れなかった ■ https://github.com/rails/rails/issues/38613#issuecom ment-595285939 ○ ミニマムな再現ケース(7行) ■ https://twitter.com/kamipo/status/12528819301035581 44 Case 1 (3)

● うまくいかなかったこと ○ minitest の--seedを固定しても、テスト実行順が固定化されなかっ た(再現したりしなかったりする原因) ○ RailsのParallel testingがAction ViewとAction Packで有効に なっているのに気づくのに時間がかかった ■ Railsガイドを修正しました ■ [skip ci] How to run Action View and Action Pack unit test in serial · Issue #38693 · rails/rails Case 1 (3)

● 最初からRubyにレポートした ○ https://bugs.ruby-lang.org/issues/16973 ■ ActiveSupportのto_jsonのテストが落ちる ● Railsのbug templateを参考にしたRubyスクリプトにした ○ Railsリポジトリをクローンしなくても再現できる ○ https://github.com/rails/rails/blob/master/guides/bug_rep ort_templates/generic_master.rb ○ gem "activesupport" - Plain Rubyスクリプトには遠い Case 2

● よかったこと ○ 意図通りで、3rd party issueとしてクローズされた ■ https://github.com/ruby/ruby/commit/41582d5866 ■ https://ruby-trunk-changes.hatenablog.com/entry/rub y_trunk_changes_20200619 に解説があります ○ Ruby側の判断を受けて、Railsが修正されました ■ https://github.com/rails/rails/pull/39697 Case 2 (2)

● よかったこと ○ 再現ケースを小さくしたり、print debugの結果を更新していたら、 Railsの該当コードレビューワーからコメントがもらえた ○ http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-cor e/98900 ● うまくいかなかったこと ○ "Without Active Support"での再現ケースはつくれなかった ○ それでも事象が解消されたことのほうが重要ではあります Case 2 (3)

最近追加されたRubyのビルド

● https://bugs.ruby-lang.org/issues/16895 が報告され、debug build(-DRUBY_DEBUG=1)つきRuby 2.8.0devが利用可能になった ○ GitHub Actions: ruby-debug ○ Docker Image: rubylang/ruby:master-debug-nightly-bionic ● Railsでは下記のpull requestがopen ○ https://github.com/rails/buildkite-config/pull/9 ● Oracle enhanced adapterでは導入済み ○ https://github.com/rsim/oracle-enhanced/pull/2015 最近追加されたRubyのビルド

Thank you