15 min/d

ぼうずやのにっき

faithcreates/hubot-fgb の review / reject コマンドをつくった

faithcreates/hubot-fgb に review / reject を追加

faithcreates/hubot-fgb に次の 2 つのコマンドを追加した。

  • @user review [<owner>/]<repo>#<issue>
  • @user reject [<owner>/]<repo>#<issue>

Issue Tracking System を Backlog から GitHub に移している。

Repository ごとの Issue を使うようにしていたのだけど 2 つの問題があった。

  • 運用が複雑になる
  • Write 権限を渡さないといけない

前者は自分たちが面倒というだけではなく、新しく人が入ったときなどの説明が難しいなどの問題もある。複雑よりはシンプルな方が良い。

後者は push してしまったり、誤ってマージする危険性があったり、新しく人が入ったときの権限の制御が難しくなる。

そこで解決策として Issue のための Repository を用意することにした。

  • Issue のための Repository は Write 権限を持つ
  • Pull Request (Source Code) のための Repository は Read 権限を持つ

これによって以下のようなメリットが得られた。

  • Issue をどのリポジトリにあるのか探さずに済む
  • Issue をどのリポジトリに登録すべきか迷わずに済む
  • Issue 以外は Read 権限にできる

代わりに Read のみになった Repository の Pull Request をレビュー依頼時に assignee を変えたり label を変えたりができなくなった。

そして、話は冒頭に戻る。

マージは以前からのコマンドがあるので、次のようなフローになる。

  1. Issue を Issue 用 Repository に登録。
  2. WIP Pull Request を Source Code 用 Repository に登録。
  3. Pull Request を rebase & force push する。
  4. Slack で @reviewer review repo#123 でレビュー依頼する。
  5. レビュアーが Slack で @reviewee reject repo#123 でリジェクトまたは @hubot merge repo#123 でマージする

シンプル!これでしばらくは運用していく。

Splatoon 30 min/d

amiibo ガールのチャレンジの 4 行目 16, 17, 20, 4 BOSS タコツボファングをクリア。ミニゲームを手に入れた。

ガチマッチは 8 勝 15 敗。負けすぎ……。ブキを変えてみている。スプラシューター。慣れていないけど N-ZAP より明らかに強い。N-ZAP 4 確ならもっと移動速度を上げても良い気がする。

comic 1 episode/d

ヒストリエ (31) エウメネスはわざと背中を切られた状態で敵陣へ。池を渡れることを敵にわざと教える。

ナルト (372) 輪廻眼。