このブログを CircleCI 2.0 & workflow 対応させてみる
仕事で CircleCI を使っているのですが、1.0 のバージョンはとにかく遅いんですよね。
docker build をさせつつ、 rspec を動かすということをやっているのですが、プロジェクトによっては X0分もかかることがあり、段々と辛くなってきました。
CircleCI 2.0 は既に高速化が見込めると話も上がっており、導入を試みていたのですが、細かい点で会社のプロジェクトではつまづくことが多かったので、とりあえず自分のブログのビルドを 2.0 対応してみることにしました。
いろんなことを一気にやろうとしすぎて、だいぶコケまくったので、そのことを書いていこうと思います。
途中、完全に master ビルドができなくなっていたのはご愛嬌。
ベースイメージに alpine を使うときに気をつけること
2.0 からはビルドに使うベースイメージを自分で DockerHub から引っ張ってこれるようになりました！速い！便利！
すると、なるべく小さいイメージを作りたくなりますよね。
じゃあ、alpine で。
となりますよね。（僕はなった）
これが、小さなハマりポイント1つ目。
restore_cache や persist_to_workspace は対象のディレクトリやファイルを tar にしてS3的なところにアップロードしているようで、ベースイメージに tar がインストールされていないとこれらの処理が必ず失敗するようになります。
tar: invalid tar magic
みたいなことを言われて失敗しちゃいます。
ベースイメージも刷新しながら、 2.0 にするときには微妙にハマるので、知っておいたほうがちょっとだけ楽ですね。
workflow の job間のデータを受け渡ししたい
workflow を導入すると、job を複数定義し、それぞれにベースイメージやら環境を設定することができます。
しかしながら、build と deploy を同じ環境下でやりたい。そして deploy は master ブランチでマージされたときだけ。となると、job は別々に定義し、実行環境は同じ。ということになります。
ここで、jobは別々に定義するけど、環境として同じものを使いたい。というときに便利なのが persist_to_workspace と attach_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分半節約できてもまぁ微妙なところだけど。。
このトライをやってみて、本業に当てれば、だいぶ良くなりそうな予感はしました。