はじめに
＊こちらはオプトテクノロジーズの社内勉強会資料になります
CircleCI2.1がPublic Previewとして使えるようになってるとのことで、早速使ってみていい感じだったので紹介しようと思います
概要
設定画面から有効にし、config.ymlのversionの値を2.1にしたら使えるようになります
CLIも2.1対応のものがリリースされているのでアップデートをお忘れなく。
目立つ機能はこんな感じ
- カスタムコマンド
- パラメタライズされたジョブ定義
- executor定義
- step実行の条件判定
- orbs（カスタムコマンド・ジョブ・executorの共有のための仕組み）
個人的にはカスタムコマンド・パラメータ利用可能なジョブとexecutor辺りがめっちゃ助かり機能。
それぞれ説明していこうと思います
カスタムコマンド
Job内の1stepとして実行可能なカスタムコマンドを定義できるようになりました。
パラメータを指定できるので、汎用性も高く、再利用しやすくなっております。
パラメータ指定については別途詳細なドキュメントがあるのでそちらを参照のこと。
例
commands:
restore_compile_cache:
parameters:
key:
type: string
steps:
- restore_cache:
name: Restore Compile Cache
keys:
- << parameters.key >>-v1-{{ checksum "build.sbt" }}-{{ .Branch }}
- << parameters.key >>-v1-{{ checksum "build.sbt" }}
パラメタライズされたジョブ定義
カスタムコマンドでも利用できたパラメータ指定がジョブでも出来るようになっています。
これによって、例えば「同じ一連のテストを異なるNode.jsのバージョンごとに実施」みたいなことがやりやすくなってます。
jobのパラメータを利用するときの注意点として、組み込みのパラメータ（ pre-steps , post-steps )があるので、これらは使えないようです。
pre-steps , post-stepsについてはこちらを参照のこと。
executor定義
stepsを実行する環境（docker imageやマシンスペックの設定といった実行環境）を定義して参照できるようになりました
もちろんこれもパラメータを利用できます
以下の例は、
- executorでnodeのイメージを定義しておき、jobではそのexecutorを使うように定義。
- job,executorでnodeのバージョンをパラメータで受けられるようにしておき、workflows定義の部分でバージョンを指定する
というパターンです
workflows:
main:
jobs:
- test:
name: test_node_6
node_version: 6.14.4
- test:
name: test_node_8
node_version: 8.12.0
- test:
name: test_node_10
node_version: 10.11.0
executors:
default:
parameters: &node_version_parameters
node_version:
type: enum
enum: ["10.11.0", "8.12.0", "6.14.4"]
working_directory: ~/work/circleci-21
docker:
- image: circleci/node:<< parameters.node_version >>
environment:
LANG: ja_JP.UTF-8
jobs:
test:
parameters: *node_version_parameters
executor:
name: default
node_version: << parameters.node_version >>
steps:
- checkout
- restore_cache:
keys:
- v1-dependencies-{{ .Branch }}-{{ checksum "yarn.lock" }}
- v1-dependencies-{{ .Branch }}-
- v1-dependencies-
- run:
name: Install dependencies
command: yarn install
- save_cache:
key: v1-dependencies-{{ .Branch }}-{{ checksum "yarn.lock" }}
paths:
- node_modules
- run:
name: Check diff (yarn.lock)
command: git diff --exit-code
- run:
name: Run Test
command: yarn test
step実行の条件判定
なんとstepの実行をするかしないか、条件に応じて決定できるようになったようです
でもパラメータとして渡された true/falseの値しか分岐に使えないので割とがっかり機能・・・
今後機能が拡張されていったら便利になるのかもしれませんが、これが乱用されるようになると相当config.ymlの治安が悪くなってしまっているような気もします。
特に便利感なかったので例はなしで（手抜き
orbs（カスタムコマンド・ジョブ・executorの共有のための仕組み）
doc:
- 構造
- 使い方
- インラインでの書き方
- orbのデザインについて
- orbの書き方とpublishについて
orbsは、よく使うコマンド・ジョブ・executorをpublishしてプロジェクト横断で使い回せるようにしましょうという仕組みです
- 通常のconfig.ymlのようにyamlファイルで定義し、カスタムコマンド・ジョブ・executorを記述できます
- orbsはnamespaceで区切られており、他のorbsと混同されることはありません
- publishをしなくても、config.yml内にorbsを定義して、それを同じconfig.ymlで使うことが出来ます
- ローカル開発で便利だよ、とドキュメントにはありましたが、自分のプロジェクトではバックエンド・フロントエンドのCIのnamespaceを切るために使ったりもしてます
- 3rd partyのOrbsを使う場合は
Orb Security Settingsの設定画面から3rdの利用をする設定を有効にしないと使えない、とドキュメントには書いてあるが設定が見つけられなかった・・・
典型的な静的サイトホスティングリポジトリとか、定形のjobなどを共有するのに良い気がします。
（使ってみようと思ったけど時間がなかったので紹介に留めました。
ビルドconfigのライフサイクルについて
新機能じゃないけどこれも紹介。
今回の変更で、動的にconfig.ymlが解決されるようになって、その辺の解決順についてなどがドキュメンテーションされてました
こちらのドキュメントにはwebhookが呼ばれてからCIの実行が終わるまでを書いてあります
2.0 -> 2.1での大きな変更としては、 項目4のconfig.ymlのパラメータなどの動的な部分が全て解決されて展開される、というところですね
CIが走り始めてconfig.ymlが文法的に正しいことが検証された次に動的な値の展開が実施され、実際にCIが走り始める時点では静的なコンフィグとして利用されるようになっています
実際に適用されることになるconfig.ymlは、Job詳細画面の Configurationタブで確認できます。
以上、CircleCI2.1の新機能紹介でした
今回の変更で相当config.ymlのメンテがやりやすくなったと思うので、CircleCIを使っているプロダクトではどんどん使っていくといいと思います
サンプルのリポジトリです
https://github.com/sisisin-sandbox/circleci-21