Summary of Circle CI 2.0

入門編 + workflowのまとめ

仕組みの概要

Jobs / Steps

  • Jobs and Steps - CircleCI
  • JobsはStepsの集合
  • 2.0ではmachine executorかdocker executorを選択できる

    • docker: キーをconfig.ymlで指定して、publicなdocker imageをJobs実行に利用できる
    • docker imageは複数指定するとlocalhostで接続できるようになる
    • docker-composeに感覚が近くて楽だった
  • Stepsはジョブ内で実行されるコマンドの集合
  • Jobs / Stepsをまず定義して、WorkflowでJobsのオーケストレーションをする

Workflows

  • Orchestrating Workflows - CircleCI
  • Jobの集合とそれの実行順を管理している
  • Workflowsを設定しない場合、buildジョブの定義が必要
  • Workflowsはconfig.ymlの最後に workflows: キーを用意する

    • versionとジョブの指定を配下で行う
    • ジョブを直列で実行する場合は、 requires: を設定していく
    • requiresを複数設定すると待ち合わせっぽくもなる
  • 他にも設定できること

    • ジョブの実行を手動で承認する設定
    • スケジューリング
    • contextを利用してjob間で環境変数をシェア
    • ブランチ / タグ指定でのJobs実行フィルタ

Cache

  • データやファイルをキャッシュ仕組みがいくつかある

    • Workspace: 1つのworkflow内でjob間のデータを保持する
    • cache: 同じjobが別のworkflowで実行されたとき用にデータを保持している
    • node_modulesとか

configファイルの概要

単体のJobsのサンプル

version: 2
jobs:
  build:
    working_directory: ~/test-circleci
    docker:
      - image: circleci/ruby:2.4-node
      - image: tkuchiki/delayed-mysql
        environment:
          MYSQL_ALLOW_EMPTY_PASSWORD: yes
          MYSQL_ROOT_PASSWORD: ''
          MYSQL_DATABASE: circleci
    steps:
      - checkout
      - run:
          name: Bundle install
          command: bundle install
      - run:
          name: Wait for DB
          # preinstalled in circleci/* docker image
          command: dockerize -wait tcp://127.0.0.1:3306 -timeout 120s
      - run:
          name: MySQL version
          command: bundle exec ruby mysql_version.rb

workspaceを設定する場合のサンプル

version: 2
jobs:
  build:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
  test:
    docker:
      - image: circleci/<language>:<version TAG>
    steps:
      - checkout
      - run: <command>
workflows:
  version: 2
  build_and_test:
    jobs:
      - build
      - test

環境変数の設定

  • 基本はconfig.ymlで設定

    • jobs / container 単位などで設定できる
  • シークレットキーなどは管理画面から環境変数を設定してファイルには書き込まない

セットアップの完了を待つ

  • docker-composeでもあった、DBのセットアップ完了やアプリの起動を待ってコマンドを実行しないとうまくいかない
  • circleciのデフォルト Docker imagesを利用すると、dockerizeコマンドが用意されている

# DBのセットアップ完了待ち
command: dockerize -wait tcp://localhost:3306 -timeout 1m

# アプリのセットアップ完了待ち(healthcheck用のエンドポイントがあればそれをリクエスト)
command: dockerize -wait http://localhost:3000/hello -timeout 2m

プロセスのバックグラウンド起動

  • commandにbackground指定すると、バックグラウンドでプロセスを起動する

    • アプリに対して実際にAPIリクエストするようなテストの場合に利用できる
      - run:
          name: Setting app process
          command: yarn start:app
          background: true

データキャッシュの具体的な設定

Workflow内でのcache

  • 別のJobsでもnpm installしたあとの状態を利用したい場合
  • persisttoworkspaceのリファレンス
  • persist_to_workspace をstepsで定義してキャッシュディレクトリのルートとパスを指定
      # ワーキングディレクトリを全部キャッシュ
      - persist_to_workspace:
          root: .
          paths:
            - .
  • 別のjobで利用する場合は attach_workspace を利用する
    steps:
      # 最初に保持していたデータをアタッチする
      - attach_workspace:
          at: .

ビルドごとのcache

  • 一度npm install したフォルダをキャッシュしておいて次回ビルドを早くする場合などに利用

  • キャッシュの保存は save_cache で行う

    • キャッシュするパスを指定
    • キャッシュを紐付けるkeyを指定

      • package.jsonのchecksumをkeyに含めている
      # キャッシュの保存
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}
  • キャッシュのrestoreは restore_cache で行う

    • keyを指定

      • 最初にpackage.josnのchecksumを含んだkeyを指定

        • package.jsonが変わっていなければ前回のキャッシュが利用できる
        • その後のyarn installがすぐ終わる
      • 該当のkeyがなければ残っているcacheを検索してくる

        • その後のyarn installで差分のモジュールがインストールされる
      • yarn install後に最新のキャッシュを保存しておく
      - restore_cache:
          keys:
          - v1-dependencies-{{ checksum "package.json" }}
          # fallback to using the latest cache if no exact match is found
          - v1-dependencies-
      - run: yarn install
      - save_cache:
          paths:
            - node_modules
          key: v1-dependencies-{{ checksum "package.json" }}