Gitlabの特定ブランチのpushをトリガにJenkinsをビルドさせる

ゴール

Gitlabへpushされたブランチによって、Jenkinsでビルドする内容を切り分けること。

• developブランチへのpush → develop-build用のJOBを起動する
• masterブランチへのpush → master-build用のJOBを起動する

イメージ

こんな感じ。

　GitlabのWebHook
　 └─> JenkinsのtriggerJOB
　　　　　 ├─> develop-build用JOB
　　　　　 └─> release-build用JOB

Jenkinsで分岐を実現するだけなのでそんなにハマるとは思ってなかったけど、その考えは甘かった。。
結論だけ知りたい人はいきなり「実現する方法まとめ」へ。

試したこと１

ParameterizedTriggerPluginを使う
https://wiki.jenkins-ci.org/display/JENKINS/Parameterized+Trigger+Plugin

イメージ

★でParameterizedTriggerPluginを使って後続のJOBを切り分ける

　GitlabのWebHook
　 └─> JenkinsのtriggerJOB ★
　　　　　 ├─> develop-build用JOB
　　　　　 └─> release-build用JOB

結果：失敗

ParameterizedTriggerPluginは後続JOBに対して、任意パラメータを付加して呼べるだけ。
後続JOB側でパラメータによって動きを変える必要があるが、develop用release用でJOBを別にする想定だったのでそもそもそんな使い方は想定していない。

試したこと２

１の構成に加えてどうにかして後続JOB側のビルド実行有無を制御する
「ビルドのパラメータ化」とか使えるのかも？

イメージ

triggerJOBがpushされたブランチ名のパラメータを付与して後続JOBを起動し、
★でパラメータが想定するブランチ名だった場合だけビルドを実行する

　GitlabのWebHook
　 └─> JenkinsのtriggerJOB
　　　　　 ├─> ★develop-build用JOB
　　　　　 └─> ★release-build用JOB

結果：失敗

そもそも何が使えるのかよくわからない。
よく考えると後続JOBを起動してから実行制御するのではなくtriggerJOBが後続を起動させないようにするほうがあるべきだと思い、却下。

試したこと３

ConditionalBuildStepPluginを使う
https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin

イメージ

★の中で、pushされたブランチ名と想定する文字列(develop,master)と比較するシェルスクリプトを実行し、条件に合致する場合は後続JOBを起動する

　GitlabのWebHook
　 └─> JenkinsのtriggerJOB ★
　　　　　 ├─> develop-build用JOB
　　　　　 └─> release-build用JOB

結果：成功

キターーーっ！！

実現する方法まとめ

　①GitlabのWebHook
　 └─> ②JenkinsのtriggerJOB
　　　　　 ├─> ③develop-build用JOB
　　　　　 └─> ③release-build用JOB

①GitlabのWebHook

Setting -> WebHookでトリガを登録する

URL : http:///job/<②のtriggerJOB名>/build?delay=0sec
Trigger: Push eventsにチェック

URLは試す環境によって他のURLだったりするかも。。
上記で動かない場合は他の記事を参考に。

②JenkinsのtriggerJOB

「ソースコード管理」→「git」にGitlabのリポジトリ名を設定する。
「SCMのポーリングをする」にチェックする。

「ビルド手順の追加」から「Conditional step(single)」を選択。（ConditionalBuildStepPlugin）
以下のように設定する。「Project to build」は実行したい③の後続JOB名を指定。

以上。ParameterizedTriggerPluginは結局使わず。

補足

pushされたブランチ名を取得するときにgit pluginで取得できる${GIT_BRANCH}を使っていたが、pushされたブランチ名ではなかったorz

結局、以下のようにして取得して、develop/masterを含むかで判断してます。

LATEST_BRANCH=`git log --pretty=format:%d -1 --all`

さらに補足 (2015/6/16)

運用していると、上記の方法では以下の様なケースでうまくいかないことがわかりました。

1. Aをcommit
2. 別ブランチでBをcommit
3. Bをpush
4. Aをpush <- このときgit logだと"B"が最新になる

そのため、コミットされたコミットID${GIT_COMMIT}からpushされたブランチを取得するように変更しました。

PUSHED_BRANCH=`git branch -r --contains ${GIT_COMMIT}`

重ね重ね修正して申し訳ありません。