CircleCI2.1の新機能紹介


はじめに

＊こちらはオプトテクノロジーズの社内勉強会資料になります

---

CircleCI2.1がPublic Previewとして使えるようになってるとのことで、早速使ってみていい感じだったので紹介しようと思います

# 概要

ドキュメントはこの辺
https://github.com/CircleCI-Public/config-preview-sdk/tree/754df2258d293775722362694d7fefa8fda5d7a0/docs
  
設定画面から有効にし、config.ymlのversionの値を2.1にしたら使えるようになります
CLIも2.1対応のものがリリースされているのでアップデートをお忘れなく。

---

目立つ機能はこんな感じ

- カスタムコマンド
- パラメタライズされたジョブ定義
- executor定義
- step実行の条件判定
- orbs（カスタムコマンド・ジョブ・executorの共有のための仕組み）

個人的にはカスタムコマンド・パラメータ利用可能なジョブとexecutor辺りがめっちゃ助かり機能。

それぞれ説明していこうと思います

---

# カスタムコマンド

doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/commands.md

Job内の1stepとして実行可能なカスタムコマンドを定義できるようになりました。
パラメータを指定できるので、汎用性も高く、再利用しやすくなっております。
パラメータ指定については別途[詳細なドキュメント](https://github.com/CircleCI-Public/config-preview-sdk/blob/0a0673db370419c265ecf7237572ad790c91cb3f/docs/parameters.md)があるのでそちらを参照のこと。


例

```yml:config.yml

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" }}

```


---

# パラメタライズされたジョブ定義

doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/jobs.md

カスタムコマンドでも利用できたパラメータ指定がジョブでも出来るようになっています。
これによって、例えば「同じ一連のテストを異なるNode.jsのバージョンごとに実施」みたいなことがやりやすくなってます。

jobのパラメータを利用するときの注意点として、組み込みのパラメータ（ `pre-steps` , `post-steps` )があるので、これらは使えないようです。
`pre-steps` , `post-steps`については[こちら](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/pre-and-post-steps.md)を参照のこと。


# executor定義

doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/executors.md

stepsを実行する環境（docker imageやマシンスペックの設定といった実行環境）を定義して参照できるようになりました
もちろんこれもパラメータを利用できます



---

以下の例は、
- executorでnodeのイメージを定義しておき、jobではそのexecutorを使うように定義。
- job,executorでnodeのバージョンをパラメータで受けられるようにしておき、workflows定義の部分でバージョンを指定する

というパターンです

---


```yml:config.yml

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実行の条件判定

doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/conditional-steps.md

なんとstepの実行をするかしないか、条件に応じて決定できるようになったようです
でもパラメータとして渡された `true`/`false`の値しか分岐に使えないので割とがっかり機能・・・
今後機能が拡張されていったら便利になるのかもしれませんが、これが乱用されるようになると相当config.ymlの治安が悪くなってしまっているような気もします。

特に便利感なかったので例はなしで（手抜き

---

# orbs（カスタムコマンド・ジョブ・executorの共有のための仕組み）

doc:　
- [構造](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/structure.md)
- [使い方](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/using-orbs.md)
- [インラインでの書き方](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/inline-orbs.md)
- [orbのデザインについて](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/design-approach.md)
- [orbの書き方とpublishについて](https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/orbs-authoring.md)

---

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のライフサイクルについて

doc: https://github.com/CircleCI-Public/config-preview-sdk/blob/754df2258d293775722362694d7fefa8fda5d7a0/docs/config-lifecycle.md

新機能じゃないけどこれも紹介。
今回の変更で、動的に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