このガイドでは、CircleCI がお客様の CI/CD パイプラインを管理する方法の基本概念について説明します。
CircleCI では、同時実行 とは複数のコンテナを使用して、複数のビルドを同時に実行することを指します。 CircleCI のすべてのお客様がシステムを安定した状態で利用できるよう、 リソースクラス ごとに同時実行数のソフト制限が設けられています。 ジョブがキュー入る場合は、この制限に達している可能性が考えられます。 年間プランのお客様は、追加料金なくこの制限の拡大を依頼することができます。
設定ファイルのサンプル に示す方法で並列実行を設定するには ワークフローのオーケストレーション を参照してください。
CircleCI では Configuration as Code の理念を掲げています。 CI/CD プロセス全体が config.yml
という 1 つのファイルを通じてオーケストレーションされます。 この config.yml
ファイルは、プロジェクトの最上部にある .circleci
というフォルダーに置かれます。 CircleCI の設定には YAML 構文が使われます。 詳しくは「 YAML の記述 」をご確認ください。
├── .circleci
│ ├── config.yml
├── README
└── all-other-project-files-and-folders
.circleci/config.yml
は、プロジェクトの全パイプラインを定義する強力な YAML ファイルです。 使用される様々なキーの概要については、 設定ファイルのリファレンス をご覧ください。
CircleCI の設定はお客様のプロジェクトの様々なニーズに合わせて変更できます。 下記の用語は粒度と依存度の順に並べられており、最も一般的な CircleCI プロジェクトのコンポーネントを表しています。
パイプライン : 設定全体を表します (Server v2.x では利用できません)。 ワークフロー : 複数の ジョブ のオーケストレーションを行います。 ジョブ : コマンドを実行する一連の ステップ を実行します。 ステップ : 依存関係のインストールやテストの実行などのコマンドやプロジェクトに必要な作業のシェルスクリプトを実行します。 下記では、
Java アプリケーション例を用いてさまざまな設定要素を紹介します。
コンテキストは、環境変数を保護し、プロジェクト間で共有するためのメカニズムを提供します。 環境変数は、名前と値のペアとして定義され、実行時に挿入されます。 コンテキストを作成したら、config.yml
ファイルのワークフローセクションで context
キーを使って、任意のジョブに当該コンテキストに関連付けられた環境変数へのアクセス権を付与することができます。
詳細は、 コンテキストの使用 を参照して下さい。
データの永続化により、ジョブ間でデータを動かし、ビルドを高速化することができます。 データを永続化するには、キャッシュ、ワークスペース、アーティファクトを使った 3 つの方法があります。
キャッシュは、依存関係、ソースコードなどを 1つのファイルとして、または複数のファイルが入ったディレクトリとしてオブジェクトストレージに格納します。 ビルドを高速化するために、各ジョブには、以前のジョブからの依存関係をキャッシュするための特別な手順が含まれている場合があります。
キャッシュをクリアする 必要がある場合は、 依存関係のキャッシュ のページで詳細をご確認ください。
version: 2.1
jobs:
build1:
docker: # Each job requires specifying an executor
# (either docker, macos, or machine), see
# circleci.com/docs/executor-intro/ for a comparison
# and more examples.
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
# template for an environment variable,
# see circleci.com/docs/caching/
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
version: 2.1
jobs:
build1:
docker: # Each job requires specifying an executor
# (either docker, macos, or machine), see
# circleci.com/docs/executor-intro/ for a comparison
# and more examples.
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
# template for an environment variable,
# see circleci.com/docs/caching/
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
version: 2
jobs:
build1:
docker: # Each job requires specifying an executor
# (either docker, macos, or machine), see
# circleci.com/docs/executor-intro/ for a comparison
# and more examples.
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
# template for an environment variable,
# see circleci.com/docs/caching/
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
ワークスペースは、ワークフロー対応のストレージ メカニズムです。 ワークスペースには、ダウンストリームジョブで必要になる可能性がある、ジョブ固有のデータが保存されます。 各ワークフローには、それぞれに一時的なワークスペースが関連付けられています。 ワークスペースは、ジョブの実行中にビルドした固有のデータを、同じワークフローの他のジョブに渡すために使用されます。
アーティファクトにはワークフローが完了した後もデータが維持され、ビルドプロセス出力の長期ストレージとして使用できます。
version: 2.1
jobs:
build1:
#...
steps:
- persist_to_workspace: # Persist the specified paths (workspace/echo-output)
# into the workspace for use in downstream job. このパスは、絶対パスまたは
# working_directory からの相対パスでなければなりません。 これは、ワークスペースの
# ルートディレクトリとなる、コンテナ上のディレクトリです。
root: workspace
# ルートからの相対パスでなければなりません。
paths:
- echo-output
build2:
#...
steps:
- attach_workspace:
# 絶対パスまたは working_directory からの相対パスでなければなりません。
at: /tmp/workspace
build3:
#...
steps:
- store_artifacts: # See circleci.com/docs/artifacts/ for more details.
path: /tmp/artifact-1
destination: artifact-file
#...
version: 2.1
jobs:
build1:
#...
steps:
- persist_to_workspace: # Persist the specified paths (workspace/echo-output)
# into the workspace for use in downstream job. このパスは、絶対パスまたは
# working_directory からの相対パスでなければなりません。 これは、ワークスペースの
# ルートディレクトリとなる、コンテナ上のディレクトリです。
root: workspace
# ルートからの相対パスでなければなりません。
paths:
- echo-output
build2:
#...
steps:
- attach_workspace:
# 絶対パスまたは working_directory からの相対パスでなければなりません。
at: /tmp/workspace
build3:
#...
steps:
- store_artifacts: # See circleci.com/docs/artifacts/ for more details.
path: /tmp/artifact-1
destination: artifact-file
#...
version: 2
jobs:
build1:
#...
steps:
- persist_to_workspace: # Persist the specified paths (workspace/echo-output)
# into the workspace for use in downstream job. このパスは、絶対パスまたは
# working_directory からの相対パスでなければなりません。 これは、ワークスペースの
# ルートディレクトリとなる、コンテナ上のディレクトリです。
root: workspace
# ルートからの相対パスでなければなりません。
paths:
- echo-output
build2:
#...
steps:
- attach_workspace:
# 絶対パスまたは working_directory からの相対パスでなければなりません。
at: /tmp/workspace
build3:
#...
steps:
- store_artifacts: # See circleci.com/docs/artifacts/ for more details.
path: /tmp/artifact-1
destination: artifact-file
#...
アーティファクト、ワークスペース、キャッシュの各機能には下記のような違いがあります。
タイプ ライフタイム 用途 例 アーティファクト 数か月 長期アーティファクトを保存します。 Job ページ の [Artifacts (アーティファクト)] タブで、tmp/circle-artifacts.<hash>container
などのディレクトリの下に表示されます。ワークスペース ワークフローの期間 attach_workspace:
ステップを使用して、ダウンストリーム コンテナにワークスペースをアタッチします。attach_workspace
を実行すると、ワークスペースの内容全体がコピーされ、再構築されます。キャッシュ 数か月 ジョブ実行の高速化に役立つ非必須データ (npm、Gem パッケージなど) を保存します。 追加するディレクトリのリストへの path
と、キャッシュを一意に識別する key
(ブランチ、ビルド番号、リビジョンなど) を指定した save_cache
ジョブ ステップ。 restore_cache
と 適切な key
を使ってキャッシュを復元する。
Docker Layer Caching (DLC ) により、 ジョブにおいてビルドされた Docker イメージの個々のレイヤーがキャッシュされます。 変更されていないレイヤーは、毎回イメージを再ビルドするのではなく、後続の実行において使用されます。
下記の config.yml
スニペットでは、build_elixir
ジョブで ubuntu-2004:202104-01
Dockerfile を使ってイメージをビルドしています。 machine
executor キーの下に docker_layer_caching: true
を追加することで、この Elixir イメージがビルドされるときに CircleCI が各 Docker イメージレイヤーを確実に保存するようになります。
version: 2.1
jobs:
build_elixir:
machine:
image: ubuntu-2004:202104-01
docker_layer_caching: true
steps:
- checkout
- run:
name: build Elixir image
command: docker build -t circleci/elixir:example .
後続のコミットでは、Dockerfile が変更されていない場合、DLC は ` build Elixir image`のステップでキャッシュから各 Docker イメージレイヤーをプルし、イメージのビルドが著しく高速化します。
詳細は、 Docker レイヤーキャッシュ を参照して下さい。
各プロジェクトの設定を手動で作成する代わりに、特定のパイプラインパラメーターまたはファイルパスに基づいて、この設定を動的に生成することができます。 これは、チームがモノレポ(単一のリポジトリ)で作業している場合に特に役立ちます。 ダイナミックコンフィグを使うと、プロジェクトの特定の 部分からビルドをトリガーできます。毎回すべてを再ビルドする必要はありません。
詳細は、 ダイナミックコンフィグ を参照して下さい。
設定内で定義された個々のジョブは、一意の実行環境で実行されます。 CircleCI ではこれらを Executor と呼んでいます。 Executor は、Docker コンテナまたは Linux、Windows、または macOS を実行する仮想マシンです。
Executor ごとにイメージを定義することができます。 イメージは、実行コンテナや仮想マシンを作成するための指示を含むパッケージ化されたシステムです。 CircleCI では、 Docker の Executor で使用するさまざまなイメージを提供しています。これを CircleCI イメージ と呼んでいます。 ビルド済み CircleCI Docker イメージの詳細については、 こちら を参照してください。
version: 2.1
jobs:
build1: # job name
docker: # Specifies the primary container image,
- image: cimg/base:2022.04-20.04
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: postgres:14.2 # Specifies the database image
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
# for the secondary or service container run in a common
# network where ports exposed on the primary container are
# available on localhost.
environment: # Specifies the POSTGRES_USER authentication
# environment variable, see circleci.com/docs/env-vars/
# for instructions about using environment variables.
POSTGRES_USER: user
#...
build2:
machine: # Specifies a machine image that uses
# an Ubuntu version 20.04 image with Docker 20.10.12
# and docker-compose 1.29.2, follow CircleCI Discuss Announcements
# for new image releases.
image: ubuntu-2004:202201-02
#...
image: ubuntu-2004:202010-01
#...
version: 2.1
jobs:
build1: # job name
docker: # Specifies the primary container image,
- image: cimg/base:2022.04-20.04
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: postgres:14.2 # Specifies the database image
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
# for the secondary or service container run in a common
# network where ports exposed on the primary container are
# available on localhost.
environment: # Specifies the POSTGRES_USER authentication
# environment variable, see circleci.com/docs/env-vars/
# for instructions about using environment variables.
POSTGRES_USER: user
#...
build2:
machine: true
# Contact your system administrator for details of the image.
#...
version: 2
jobs:
build1: # job name
docker: # Specifies the primary container image,
- image: cimg/base:2022.04-20.04
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: postgres:14.2 # Specifies the database image
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
# for the secondary or service container run in a common
# network where ports exposed on the primary container are
# available on localhost.
environment: # Specifies the POSTGRES_USER authentication
# environment variable, see circleci.com/docs/env-vars/
# for instructions about using environment variables.
POSTGRES_USER: user
#...
build2:
machine: true # Specifies a machine image.
# Contact your system administrator for details of the image.
#...
プライマリコンテナは、 .circleci/config.yml
ファイルに最初にリストされているイメージによって定義されます。 ここでコマンドが実行されます。 Docker Executor は、Docker イメージを使用してコンテナを起動します。 Machine Executor は完全な Ubuntu 仮想マシン イメージを起動します。 比較表と考慮事項については、 Executor の概要 を参照してください。 さらにイメージを追加して、セカンダリ / サービスコンテナをスピンアップできます。
Docker Executor を使って Docker コマンドを実行する際のセキュリティを強化するために、setup_remote_docker
キーを使用して、これらのコマンドを実行する別の Docker コンテナをスピンアップできます。 詳細は、 Docker コマンドの実行 ガイドを参照して下さい。
注: macOS は CircleCI Server v 2.x. では使用できません。
イメージは、実行コンテナを作成するための指示を含むパッケージ化されたシステムです。 プライマリコンテナは、 .circleci/config.yml
ファイルに最初にリストされているイメージによって定義されます。 ここで、Docker または Machine Executor を使用してジョブのコマンドが実行されます。
Docker Executor は、Docker イメージを使用してコンテナをスピンアップします。 CircleCI では一般的なプログラミング言語に対応する CircleCI イメージ を Docker Hub 上に用意しています。
Machine Executor は完全な Ubuntu 仮想マシンイメージをスピンアップします。これにより、OS リソースへのフルアクセスやジョブ環境の完全な制御が可能になります。 詳細は、 マシンの使用 を参照して下さい。
詳細は、 実行環境の概要 のページを参照してください。
version: 2.1
jobs:
build1: # job name
docker: # Specifies the primary container image,
# see circleci.com/docs/circleci-images/ for
# the list of pre-built CircleCI images on dockerhub.
- image: cimg/base:2022.04-20.04
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: postgres:14.2 # Specifies the database image
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
# for the secondary or service container run in a common
# network where ports exposed on the primary container are
# available on localhost.
environment: # Specifies the POSTGRES_USER authentication
# environment variable, see circleci.com/docs/env-vars/
# for instructions about using environment variables.
POSTGRES_USER: user
...
build2:
machine: # Specifies a machine image that uses
# an Ubuntu version 20.04 image.
# The image uses the current tag, which always points to the most recent
# supported release. If stability and determinism are crucial for your CI
# pipeline, use a release date tag with your image, e.g. ubuntu-2004:202201-02
image: ubuntu-2004:current
...
build3:
macos: # Specifies a macOS virtual machine with Xcode version 12.5.1
xcode: "12.5.1"
...
ジョブは設定の構成要素です。 また、必要に応じてコマンド / スクリプトを実行する ステップ の集まりです。 各ジョブでは、docker
、machine
、windows
、macos
のいずれかの Executor を宣言する必要があります。 docker
の場合、プライマリコンテナで使うには イメージを指定する 必要があります。 macos
の場合、 Xcode のバージョン を指定する必要があります。 windows
の場合、 Windows Orb を指定する必要があります。
Orb は、再利用可能なコードスニペットです。Orb を使用すると、繰り返しのプロセスを自動化でき、手早くプロジェクトをセットアップできます。サードパーティ製ツールとの連携も容易になります。 設定ファイルで Orb を使用する方法と Orb 設計の概要については、 Orb のコンセプト を参照してください。 CircleCI Orb レジストリ では、構成作業の簡素化に役立つ Orb を検索できます。
設定 セクションの図は、Orb を使用して Java 設定を簡素化する例です。 下記の図では、 Maven Orb を使って簡易化された設定を紹介しています。 ここでは Orb は、Maven でステップを実行し共通のジョブを実行できるデフォルトの Exexcutor を設定しています (maven/test
) 。
プロジェクトに含まれるテストの数が多いほど、テストを 1 台のマシンで実行するのに時間がかかるようになります。 並列実行 により、指定した数の別々の Executor にテストを分散することができます。
テストスイートは通常、.circleci/config.yml
ファイルの ジョブ レベルで定義します。 parallelism
キーには、ジョブのステップを実行するためにセットアップする独立した Executor の数を指定します。
ジョブのステップを並列に実行するには、parallelism
キーに 1 よりも大きい値を設定します。
# ~/.circleci/config.yml
version: 2.1
jobs:
test:
docker:
- image: cimg/<language>:<version TAG>
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
parallelism: 4
詳細は、 テストの並列実行 を参照して下さい。
CircleCI パイプラインとは、プロジェクトで作業をトリガする際に実行する一連のプロセスすべてを指します。 パイプラインには、ジョブを管理するワークフローが含まれます。 これらは全てプロジェクトの 設定ファイル で定義されます。 ハイプラインは CircleCI Server v2.x では使用できません。
パイプラインとは、設定と対話するための手法です。
パイプラインのトリガー エンドポイントを使って API 経由でパイプラインをトリガーする パイプラインのパラメーターを使って 条件付きワークフロー をトリガーする version 2.1
を使うことで、下記が利用できます。 Executor、コマンド、ジョブなどの 再利用可能な設定ファイル エレメント Orb として知られるパッケージ化された再利用可能な設定ファイル。 改善された設定ファイルの検証エラーメッセージ Advanced Settings で自動キャンセルを有効化するオプション。新しいパイプラインが非デフォルトのブランチでトリガーされた場合にワークフローを終了します。(GitHub と Bitbucket をご利用の場合、自動キャンセルが利用できます。) 非デフォルトのブランチで自動デプロイジョブを設定している場合など、自動キャンセル機能の有効化による影響を慎重に検討する必要があります。
CircleCI のプロジェクトは、お客様の バージョンコントロールシステム (VCS) 内の、関連するコードリポジトリの名前を共有します。 CircleCI アプリのサイドバーから Projects を選択し、プロジェクトダッシュボードに入力します。 ここからアクセス可能なプロジェクトの設定やフォローが可能です。
プロジェクトダッシュボードで、以下のいずれかを実行します。
VCS で所有者になっているプロジェクトを セットアップ する. 組織内のプロジェクトを フォロー して、パイプラインにアクセスし、プロジェクトのステータスに関する メール通知 を受け取る
リソースクラスは、ジョブで利用可能なコンピューティングリソースを制御できる設定オプションです。 ジョブの実行環境を指定すると、 設定ファイル でリソースクラスが定義されて いない場合 、その環境にはデフォルトのリソースクラスの値が設定されます。 デフォルト値にするよりもリソースクラスを指定することをお勧めします。
下記の例では Docker 実行環境でリソースクラスを定義する方法を紹介します。
jobs:
build:
docker:
- image: cimg/node:current
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
resource_class: large
すべての実行環境の例は、下記ページでご確認いただけます。
各種リソースクラスの料金とプランに関する情報は リソースクラス 製品のページをご覧ください。
resource_class
キーは、 セルフホストランナーインスタンス の設定にも使用されます。
ステップは通常、ジョブを完了するために必要な実行可能コマンドの集まりです。 たとえば以下の例では、 checkout
ステップ (すべての CircleCI プロジェクトで使用できるビルトインステップ) が SSH コマンドでジョブのソースコードをチェックアウトします。 次に、run
ステップで、デフォルトで非ログインシェルを使用して、make test
コマンドなどのカスタムコマンドを実行します。 コマンドは、 ジョブ宣言の外部 に定義することもでき、設定全体で再利用することができます。
#...
jobs:
build:
docker:
- image: <image-name-tag>
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout # Special step to checkout your source code
- run: # Run step to execute commands, see
# circleci.com/docs/configuration-reference/#run
name: Running tests
command: make test # executable command run in
# non-login shell with /bin/bash -eo pipefail option
# by default.
#...
ここでは CircleCI プロジェクトに関連するユーザータイプを紹介します。 多くのユーザーは、 VCS アカウントから継承された権限を持っています。
ワークフローは、ジョブをオーケストレーションします。 ワークフローは、ジョブのリストとその実行順序を定義します。 ジョブは、同時実行、順次実行、スケジュール実行、あるいは承認ジョブを使用した手動ゲートによる実行が可能です。
下記の設定サンプルでは、build_and_test
というワークフローを紹介しています。build1
ジョブを実行し、その後 build2
ジョブと build3
ジョブを同時に実行します。
version: 2.1
jobs:
build1:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: Running tests
command: make test
build3:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: アセットのプリコンパイル
command: bundle exec rake assets:precompile
#...
workflows:
build_and_test: # name of your workflow
jobs:
- build1
- build2:
requires:
- build1 # wait for build1 job to complete successfully before starting
# see circleci.com/docs/workflows/ for more examples.
- build3:
requires:
- build1 # wait for build1 job to complete successfully before starting
# run build2 and build3 concurrently to save time.
version: 2.1
jobs:
build1:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: Running tests
command: make test
build3:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: アセットのプリコンパイル
command: bundle exec rake assets:precompile
#...
workflows:
build_and_test: # name of your workflow
jobs:
- build1
- build2:
requires:
- build1 # wait for build1 job to complete successfully before starting
# see circleci.com/docs/workflows/ for more examples.
- build3:
requires:
- build1 # wait for build1 job to complete successfully before starting
# run build2 and build3 concurrently to save time.
version: 2
jobs:
build1:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- checkout
- save_cache: # Caches dependencies with a cache key
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
paths:
- ~/circleci-demo-workflows
build2:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: Running tests
command: make test
build3:
docker:
- image: cimg/ruby:2.4-node
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
- image: cimg/postgres:9.4.12
auth:
username: mydockerhub-user
password: $DOCKERHUB_PASSWORD # context / project UI env-var reference
steps:
- restore_cache: # Restores the cached dependency.
key: v1-repo-{{ .Environment.CIRCLE_SHA1 }}
- run:
name: アセットのプリコンパイル
command: bundle exec rake assets:precompile
#...
workflows:
version: 2.1
build_and_test: # name of your workflow
jobs:
- build1
- build2:
requires:
- build1 # wait for build1 job to complete successfully before starting
# see circleci.com/docs/workflows/ for more examples.
- build3:
requires:
- build1 # wait for build1 job to complete successfully before starting
# run build2 and build3 concurrently to save time.
はじめてのビルドの成功(グリーンビルド) では、動作中のパイプラインを設定する方法を順を追って紹介しています。