BuildHiveに直接プッシュできるようになりました

BuildHiveではリリース当初からプルリクエストを自動ビルドする機能がついていますが、今日、これに加えて開発者がBuildHiveに直接変更をgit pushする仕組みを追加しました。この仕組みは「検証済みマージ」といいます。

プルリクエストは主に外部の開発者が変更を提案したり、コミッタが他のコミッタに対してコードレビューを依頼する時などに使われる仕組みです。なので、通常、開発者は自分の変更をわざわざプルリクエストにせず、直接リポジトリへプッシュしているのではないかと思います。ただし、それだと問題のあるコミットがリポジトリに混入してビルドが壊れる、ということが起こりえます。検証済みマージをすることで、これを防ぐことができます。この機能は次のように動作します。

まず、GitHub上でbuildhiveユーザーをリポジトリのコラボレータとして追加してください。これによって、BuildHiveがリポジトリに変更をプッシュできるようになります。BuildHiveがこれを自動でやるのはまずいかと思ったので、現時点ではこれは手動でおこなってもらう必要があります。

次に、BuildHiveにログインして、ジョブのページを表示してください（例）。画面左から「Git Repository for Validated Merge」を選びます。コピーボタンを押して、「git remote add」コマンドをクリップボードへコピーし、このコマンドをワークスペースで実行してください。これでBuildHiveがリモートリポジトリとして追加されます。

準備はこれで出来上がりなので、いつもやっているようにコードを編集し、コミットを作ってください。プッシュする用意が整ったら、いつものように「origin」にプッシュするのではなく、「jenkins」にプッシュしましょう。下の例ではmasterブランチをプッシュしていますが、他のブランチで作業していたらその名前に置き換えてください。

$ git push jenkins master

BuildHiveは変更を受け取ると、GitHub上での現在のそのブランチの先端とマージした上で、ビルドとテストを行います。もしマージの結果がテストに合格した場合は、そのマージの結果がGitHubへプッシュされます。

もし運悪く、変更に不備があれば、テスト失敗が通知されます。その時点でやりかけだった仕事を一度中断して、不備のあった変更を最修正しましょう。どの変更をBuildHiveにプッシュしたか覚えておくのは面倒なので、BuildHiveは不備のあった変更をチェックアウトしやすいようにタグを公開してくれます。コマンドをコピペしてタグを取得しましょう。

$ git stash

$ git fetch -n ssh://[email protected]/kohsuke2/sandbox-ant tag changes/45

$ git checkout changes/45

$ … make edits ...

不備のあった変更に新たなコミットを追加して問題を修正してもいいですし、rebaseやcommit --amendなどを使って破壊的な変更をおこなっても構いません。不備を修正したら、それを改めてBuildHiveに送ってテストしましょう。BuildHiveに修正を送ったら、前に行なっていた作業に戻りましょう。

$ git push jenkins HEAD:master

$ git checkout master

$ git stash pop

… resume the work you were doing ...

もし変更の不備が発見された時にあなたが既に帰宅していたら、他の同僚がかわってこの作業を行うこともできます。

開発者の時間は貴重です。開発マシンがテストの実行を終えるのを待つのではなく、さっさと変更をBuildHiveに送ってしまって、次の作業にとりかかりましょう！この機能を利用すれば、開発者はテストの実行をローカルで行う必要はなくなります。編集→コミット→プッシュだけを繰り返せばいいのです。

なお、この機能はJenkins Enterprise by CloudBeesについている機能をBuildHive上に展開したものです。Jenkins Enterprise by CloudBeesを使えばこのような作業フローを任意のGitリポジトリに対して利用できます。