Skip to content

Instantly share code, notes, and snippets.

@willnet
Last active August 21, 2023 05:44
Show Gist options
  • Save willnet/ca970b2033846fe3e30a8696eb39fbd5 to your computer and use it in GitHub Desktop.
Save willnet/ca970b2033846fe3e30a8696eb39fbd5 to your computer and use it in GitHub Desktop.
Railsコントリビュータへの道

これはなに

  • Railsにプルリクストを送るときに知っておくと便利なお作法集
  • Railsにプルリクエストを送りたいけど何から始めたらいいのかわからない人向けの指針

お作法についてはRuby on Rails に貢献する方法 | Rails ガイドを参考にしています。

前提知識

Railsのコードを読むには、最低限次の二つの知識があったほうがよいです

テスト環境

  • rails 自体のテストは rails-dev-box にある vagrant 環境越しにやります
  • 基本的に各ライブラリ(例: activerecord)のディレクトリで rake test して実行します。全体は時間かかりすぎる><

rails で単体のテストファイルを実行する方法

bundle exec ruby -w -Itest:lib テストファイル名

ex)
bundle exec ruby -w -Itest:lib test/core_ext/hash_ext_test.rb

単体ファイルの特定のテストを実行する方法

bundle exec ruby -w -Itest:lib テストファイル名 -n テスト名

ex)
bundle exec ruby -w -Itest:lib test/core_ext/hash_ext_test.rb -n test_transform_keys

Issue のお作法

  • Issue にテンプレートがあるのでそれを埋めましょう
  • 再現コードのひな形あるのでそれを参考に動く再現手順を作りましょう
  • 他の人が作ったIssueに再現手順がなかったら、つくってあげると喜ばれるかも

PR のお作法

  • ドキュメントやコメントの typo 修正は、コミットに [ci skip] を必ずつけること
  • PRのテンプレートがあるのでなるべく埋めましょう
  • コミットはなるべく一つにまとめましょう
    • PRした後に指摘来たらsquashせずにコミットを追加
    • マージする段階になったらsquashしてねと言われるはず
  • バグ修正以外のPRは、「このPRが入るとなにが良くなるのか」をなるべく具体的に書きましょう
    • ここが明確でないPRは放置されたりcloseされたりしがち

PR するためになにをすると良いか

  • edge Rails をなるべく毎日さわる。
    • 新機能が追加されたら一通り使ってみるとバグに気づきやすい
  • TODO:FIXME: で検索する
  • DHH が立てた Issue をウォッチする
  • コミットを読む
  • コードを読む
    • 最初は ActiveSupport が読みやすいのでオススメ
  • マージされると Rails Contributors に自分の名前が載るので見てニヤニヤしましょう

便利なサービス

登録したOSSのPRやIssueを毎日メールで通知してくれる

CodeTriage

その他

@y-yagi
Copy link

y-yagi commented Jun 16, 2016

私はあと以下のような事を気にしてたりします。ご参考までに。

  • コードを書く際はRailsコーディングルールに従う
  • 再現コードのひな形は、Active Record用 / Action Controller用 / その他用で3種、そしてそれぞれmaster用 / gem用の合計6種類あるので、必要に応じて適切なものを選ぶと良い
  • 既にissueがあるバグの修正を行う際は、コミットログにそのissueの番号を入れる。そうするとPRとissueが自動で紐付けられるので、何のバグfixかわかりやすくなる。
  • 性能改善の対応を行う場合は、コミットログにベンチマークに使用したスクリプト、及びその結果をまるまる含んでしまう
  • Active RecordのテストはデフォルトでMySQL / PostgreSQL / SQLite3それぞれのDBに対してテストが実行されるので、割と時間がかかる。 特定のDBに対してだけテストを行いたい場合は、ARCONNでDBを指定してテストを行う。 また、DBに依存しないテストを行いたい場合は、SQLite3のin-memory DBを使用する。大分早くい。詳細はRUNNING_UNIT_TESTS.rdoc参照。

@willnet
Copy link
Author

willnet commented Jun 16, 2016

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment