Mozilla 関係のプロダクトにコントリビュートするとよく見かける (?) ，bors というボットがいます．たとえば，普段コントリビュートするみなさんもこういったコメントを見たことがあるかと思います．
@bors-servo r+
普段は自分でキックすることはないので，基本レビュワーの方々に任せておけばいいかな〜というスタンス（そしてコケたら対応すればいいやのスタンス）なのですが，せっかくの機会なのでいろいろ調べてみることにしました．
そもそも bors とは
裏側は Homu というツールが動いています．Homu とは，リポジトリのコードのすべてのテストがいつも通っている状態を自動的にキープしてくれるツールのことです．自動テストツールといったところでしょうか．
個人の方が作っていた OSS です．ただ作者の方はもう GitHub 上ではアクティブではないため，Servo が fork してメンテナンスして使っているようです．
公式ガイドによると次の手順で動作するようです．
- 開発者の working branch はいつもどおりアップロードされる (要するに fork なりした branch から普通に commit & push するということですかね)．
- レビュワーがコードをチェックして大丈夫そうならば，Homu に対してメッセージを送る (Servo なら
@bors-servo r+などというコメントを見ますね)． - Homu は master ブランチにマージを行う (が，それは本当の master とは別になっていて
autoと呼ばれるもの)． - サーバーのクラスタ内で，すべての OS に対するテストが行われる．
- クラスタが OK を返すと，Homu は auto を master にコピーしたと返答する．
- クラスタが NG を返すと，Homu はそのエラーレポートを返す．何もしない．
コマンドのチートシート
詳しくはこのガイドに載っています．
よく見るものだけ軽くまとめておきます．
- r+: PR の承認を意味します．これが出るとだいたい OK 感ある．bors の種々のテストが行われた後，マージされてその PR は Close となります．
- try=xxx: 承認なしでテストだけ走らせることができます． PR を投げた直後に飛ばしていました．try → テストが OK → r+ の流れな気がします．
- retry: 文字通り retry します．普通にテストが別のツールで通っているのに落ちることがあり，変だなと思ったら投げているようですね．
Issue は自動的に閉じられる
担当した Issue は，bors-servo が最後に自動的に閉じて後片付けまでしてくれます．これなら閉じ忘れも起きませんね．
Servo の開発においては，あらゆることが自動化されていて，OSS とはこういう感じなんだなあという勉強になることが多いです．
小ネタでした．
