作ったソースコードとCircleCIの設定
.circleci/config.yml
version: 2.1 orbs: win: circleci/windows@2.2.0 jobs: build: executor: win/default steps: - checkout - run: dotnet build - persist_to_workspace: root: . paths: - . test: executor: win/default steps: - attach_workspace: at: . - run: dotnet test workflows: version: 2.1 build-test: jobs: - build - test: requires: - build
buildとtestでジョブを分けて、workflowsでそれぞれのジョブが順番に実行されるように設定しています。ポイントは2か所です。
- persist_to_workspace を使ってbuildジョブの結果をtestジョブで使えるようにしている
- testジョブはbuildジョブの終わりを待つように requires を設定している
buildジョブ
ソースコードをチェックアウト+ビルドした後、データを保存して他のジョブでも使えるようにしています。データを保存する設定がpersist_to_workspaceです。
circleci.com
persist_to_workspaceの部分を抜粋
- persist_to_workspace: root: . paths: - .
persist_to_workspace は各ジョブがアクセスできるワークスペースと呼ばれる場所にデータをコピーする設定です。rootとpathsでコピー元を設定します。上記の設定はワーキングディレクトリ以下がすべてコピーされます。
特定のディレクトリのコピーも可能でリファレンスに書かれている以下の設定はworkspace/echo-outputディレクトリがコピーされます。
# 後に続くジョブで利用できるように Workspace に指定のパス(workspace/echo-output)を保存します。 - persist_to_workspace: # working_directory からの相対パスか絶対パスを指定します。 # これは Workspace のルートディレクトリとなるコンテナ内のディレクトリです root: workspace # root からの相対パスを指定します paths: - echo-output
testジョブ
buildジョブでワークスペースに保存した結果をダウンロードし、testコマンドを実行しています。データをダウンロードする設定がattach_workspaceです。
circleci.com
attach_workspaceの部分を抜粋
steps: - attach_workspace: at: . - run: dotnet test
attach_workspaceはワークスペースにコピーしたデータをダウンロードする設定です。atの設定でダウンロード先を設定します。上記はワーキングディレクトリにダウンロードしています。
dotnet test は単体テストを実行するコマンドです。
docs.microsoft.com
workflows
ワークフローはジョブの実行を制御する設定でジョブを並列に実行させたり、順番通りに実行させたり、スケジュールを計画し実行させたり出来ます。
circleci.com
今回はbuildジョブの結果をtestジョブが使います。build→testと順番通りに実行して欲しいためワークフローを使っています。
workflowsの部分を抜粋
build-test: jobs: - build - test: requires: - build
testステップでrequiresを指定しています。requires: は記述されたジョブが問題なく完了するまで、処理が待機されるため順番が保証されます。
例えばbuildでエラーになった場合は以下のようにtestは実行されません。
まとめ
Workflowsを使うとジョブの実行が柔軟になります。今回はrequiresを使いましたが他の設定も調べてまとめたいと思います。