CircleCI 2.0 と workflow に対応しました

03 July 2017 on circleci

このブログを CircleCI 2.0 & workflow 対応させてみる

仕事で CircleCI を使っているのですが、1.0 のバージョンはとにかく遅いんですよね。

docker build をさせつつ、 rspec を動かすということをやっているのですが、プロジェクトによっては X0分もかかることがあり、段々と辛くなってきました。

CircleCI 2.0 は既に高速化が見込めると話も上がっており、導入を試みていたのですが、細かい点で会社のプロジェクトではつまづくことが多かったので、とりあえず自分のブログのビルドを 2.0 対応してみることにしました。

いろんなことを一気にやろうとしすぎて、だいぶコケまくったので、そのことを書いていこうと思います。

途中、完全に master ビルドができなくなっていたのはご愛嬌。

ベースイメージに alpine を使うときに気をつけること

2.0 からはビルドに使うベースイメージを自分で DockerHub から引っ張ってこれるようになりました!速い!便利!

すると、なるべく小さいイメージを作りたくなりますよね。

じゃあ、alpine で。

となりますよね。(僕はなった)

これが、小さなハマりポイント1つ目。

restore_cachepersist_to_workspace は対象のディレクトリやファイルを tar にしてS3的なところにアップロードしているようで、ベースイメージに tar がインストールされていないとこれらの処理が必ず失敗するようになります。

tar: invalid tar magic

みたいなことを言われて失敗しちゃいます。

ベースイメージも刷新しながら、 2.0 にするときには微妙にハマるので、知っておいたほうがちょっとだけ楽ですね。

workflow の job間のデータを受け渡ししたい

workflow を導入すると、job を複数定義し、それぞれにベースイメージやら環境を設定することができます。

しかしながら、build と deploy を同じ環境下でやりたい。そして deploy は master ブランチでマージされたときだけ。となると、job は別々に定義し、実行環境は同じ。ということになります。

ここで、jobは別々に定義するけど、環境として同じものを使いたい。というときに便利なのが persist_to_workspaceattach_workspace です。 参考

ここがハマりポイント2つ目。。

persist_to_workspace と attach_workspace の書き方

公式ドキュメント には

- persist_to_workspace:
    paths: /tmp/file-name

とあるのですが、 root というキーと値が指定されていないと not relative to the workspace root というエラーが出てコケてしまいます。。

ドキュメントを舐めるようにみても、わからず、フォーラムの方で他の人がこういう感じで書いているのを見て、ようやくわかりました。。

正しくは

- persist_to_workspace:
  root: YOUR_ROOT_PATH
  paths: TARGET_DIRECTORY

と書いてあげる必要があったのでした。。(わかりにくい)

ここで、もう一つコツがあります。 この永続化した workspace を他のjobで展開するときに attach_workspace を使うのですが、そこではこういう書き方をします。

- attach_workspace:
    at: YOUR_ROOT_PATH

TARGET_DIRECTORY を永続化して、他のjobで展開したいときにこう書くのですが、なんかもうちょっとスッキリかけるといいですね。。

参考情報

本ブログの circleci 2.0 対応 → .circleci/config.yml

ベースイメージの Dockerfile → Dockerfile

ちなみに、肝心の高速化状況ですが↓に乗せています。

2分くらいだった build & deploy の時間は、 30秒へ。

速い。ちっこいプロジェクトだから、1分半節約できてもまぁ微妙なところだけど。。

このトライをやってみて、本業に当てれば、だいぶ良くなりそうな予感はしました。