「再現ケース」の必要性とその難しさ

銀座Rails#23

Transcript

1. 銀座Rails#23 July 4, 2020 Yasuo Honda @yahonda 「再現ケース」の必要性とそ の難しさ
2. • 依存するライブラリやプログラムの変更で、アプリケーションやフレーム ワークに問題が出たときに、どうレポートするか • Rubyの変更でRailsのCIが落ちたときの例を元にうまくいったこと、うまく いかなかったこと • 技術的な側面よりも、どのように考えるか、どのように行動するかをお話し します 話すこと
3. • 開発中の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
4. • Rubyのどのcommitが現象を引き起こしたか特定する ◦ git bisect を利用 ◦ How to git bisect ruby/ruby repository 参照のこと • 現象が再現する手順を確立する ◦ minitest_bisect を利用する ◦ https://gist.github.com/yahonda/b67b19304d34fc1150a9db 79ee325bcc 参照のこと ◦ この時点ではRubyにとって”ミニマムな”再現手順ではない ◦ "ミニマム"の意味はリポジトリにより異なる Rubyの変更でRailsのCIが落ちたらやること
5. • 考えられる選択は以下のいずれか • 現象が発生したRailsのissues ◦ Issues · rails/rails · GitHub • 現象を引き起こした(と報告時点では考えている) Rubyのissues ◦ Ruby Issue Tracking System 再現できたらどこにレポートするか
6. • 現象が発生したレポジトリ ◦ 私はずっとこうしていた(Railsのissueとして報告していた) • いいところ ◦ 再現ケースはRailsのUnit testなので、Railsフレームワーク開発者 にとってなじみがある(ミニマムなテストケースといえる) • よくないところ ◦ Rubyの非互換性の可能性があっても、Rails側で「直してしまう」場合 がある 再現できたらどこにレポートするか(2)
7. • 現象のきっかけとなったレポジトリ ◦ いまはこうしています(bugs.ruby-lang.orgにまずレポート) • いいところ ◦ Ruby開発者にRubyの非互換性や問題を直接レポートできる ◦ 非互換性や問題はRuby開発者が意図している場合と意図していな い場合があることがわかる ◦ Rubyが直る場合とRailsが修正される場合がある ▪ 意図しているRubyの非互換性であれば、現象が発生したレポジ トリ(Rails)で修正を行うことになる 再現できたらどこにレポートするか(3)
8. • よくないところ(難しいところ): ◦ ミニマムな再現ケースを作りにくい ◦ Ruby開発者にとってはRailsフレームワークのunit testはミニマム ではない ◦ Railsのunit testをplainなRubyでの再現ケースにするのは大変 ▪ 私自身ほとんどできていない • Note: 100%の再現性を特定できていない場合 ◦ 現象が発生したレポジトリで、再現性を高めるための情報を得ましょ う 再現できたらどこにレポートするか(4)
9. 実際の例2つ
10. • 最初は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
11. • よかったこと ◦ 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)
12. • うまくいかなかったこと ◦ 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)
13. • うまくいかなかったこと ◦ 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)
14. • 最初から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
15. • よかったこと ◦ 意図通りで、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)
16. • よかったこと ◦ 再現ケースを小さくしたり、print debugの結果を更新していたら、 Railsの該当コードレビューワーからコメントがもらえた ◦ http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-cor e/98900 • うまくいかなかったこと ◦ "Without Active Support"での再現ケースはつくれなかった ◦ それでも事象が解消されたことのほうが重要ではあります Case 2 (3)
17. 最近追加されたRubyのビルド
18. • 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のビルド
19. Thank you