Shippableでまた落とし穴にハマった話 PR作成編

shippable 技術系日記

この前こういう記事書いたらそこそこ伸びたようでありがとうございます。
ウチでも使ってるよ的な話は聞けてないので、使ってる方は是非なにか書いてもらえると嬉しいです。

hkdnet.hatenablog.com

さて、また落とし穴にハマったので日記です。今回のは僕はびっくりしたけどそうでもない人もいるかも。

Pull Request と 環境変数$BRANCH

PR作成したときにハマった落とし穴の話です。
コンボが決まると意図しないデプロイが走ったりすると思うんでお気をつけ下さい。

Pull Request

ShippableではpushをフックしてCIが走ります。まあいわゆるCIサービスとしては普通ですね

実はそれ以外にPull Requestの作成時にもCIが走ります。
なのでPR作成直後は必ずそのPRはCIステータスが黄色(Running)になります。CIが通るまで待ちましょう

僕はCircleCIとShippableくらいしか使ったことがないんですがPR作成時にCIが走るのって一般的なんでしょうか？

環境変数$BRANCH

ShippableにおいてShippable側が用意してくれている環境変数が多数あります。
前回の記事で紹介した $SHIPPABLE_CONTAINER_NAME や $SHIPPABLE_BUILD_DIR などもそうです。
そういったCI環境の設定値以外に、メタなデータとしてブランチ名がはいっている $BRANCH やビルド番号がはいっている$BUILD_NUMBER などもあります。

topic-aブランチでCIをまわしたときは $BRANCH は何がはいるでしょうか。当然 "topic-a" ですよね。

では上述のPullRequest作成時を考えます。topic-aからmasterブランチにPRを作ったときは$BRANCHは何になりますか。
これは "master" になります。

ふーん……

なんでだよ！！！

いやまあ確かにPR作成時に走るCIなので最終コミットと全く同じ状態でやってもしょうがないんですけど……。

これを踏まえて、「masterの最新の状態をlatestタグをつけてdocker pushしたい」というのはこんな感じになります。*1
条件の前半を省略するとまだmasterにマージされてないPRの段階でlatestをpushしちゃうので気をつけてください。

if [ "$IS_PULL_REQUEST" = "false" ] && [ "$BRANCH" = "master" ]; then
  docker tag さっきビルドしたやつ hkdnet/awesome_image:master;
  docker push hkdnet/awesome_image:master;
fi;

最初は混乱したこの2つの仕様ですが、以下のように考えたらなんとなく納得できるようになりました。

PR作成 → ということは動作確認の機会がある → これからマージされるやつと同じ環境変数でビルドしたイメージを作りたい

逆に "$IS_PULL_REQUEST" = "true" なら動作確認環境へデプロイみたいな感じのことをするとステキかもしれませんね。

*1:そらで書いてるんで違ったらごめんなさい