Ubuntu16.04でConcourseCIを使用して継続的インテグレーションパイプラインを設定する方法
序章
Concourse CI は、構成可能な宣言型構文を使用してパイプラインのテストを自動化するように設計された、最新のスケーラブルな継続的インテグレーションシステムです。 以前のガイドでは、Ubuntu16.04サーバーにConcourseをインストールし、Let'sEncryptのSSL証明書を使用してWebUIを保護しました。
このガイドでは、新しい変更がリポジトリにコミットされたときに、Concourseを使用してプロジェクトのテストスイートを自動的に実行する方法を示します。 実例を示すために、Node.jsWebフレームワークであるHapi.jsで記述された「helloworld」アプリケーションの継続的インテグレーションパイプラインを構成します。
ビルドとテストの手順が、関連付けられているコードと常に同期していることを確認するために、CI定義をアプリケーションリポジトリ自体に追加します。 その後、Concourseのflyコマンドラインツールを使用して、パイプラインをConcourseにロードします。 最後に、変更をリポジトリにプッシュバックして、変更をより永続的に保存し、新しいCIワークフローで新しいテストを開始します。
前提条件
始める前に、少なくとも1GのRAMを備えたUbuntu16.04サーバーが必要です。 次のガイドを完了して、root以外のユーザーを設定し、Concourseをインストールして構成し、Nginxをインストールし、TLS / SSL証明書を取得し、ConcourseWebUIへの安全なリバースプロキシを設定します。 Concourseサーバーを適切に保護するには、Concourseサーバーを指すドメイン名が必要です。
- Ubuntu16.04でのサーバーの初期設定
- Ubuntu16.04にConcourseCIをインストールする方法
- Ubuntu16.04にNginxをインストールする方法
- Ubuntu16.04でLet'sEncryptを使用してNginxを保護する方法
- Ubuntu16.04でNginxを使用してSSLでConcourseCIを保護する方法
このチュートリアルでは、ほとんどの作業はConcourseサーバーではなくローカルコンピューターで完了します。 そのため、ローカルマシンでいくつかのツールが使用可能であることも確認する必要があります。 リポジトリ内のファイルを作成および変更するには、テキストエディタ（さまざまなオペレーティングシステムで見られる可能性のあるいくつかの例として、nano、vim、TextEdit、Sublime Text、Atom、またはメモ帳）が必要です。 また、ローカルシステムにGitをインストールしてセットアップする必要があります。これは、オープンソースへの貢献：Gitの開始ガイドに従って行うことができます。
Concourseサーバーをセットアップし、Gitとテキストエディターをローカルコンピューターにインストールしたら、以下に進みます。
Flyコマンドラインツールをローカルにインストールする
前提条件でサーバーにConcourseをインストールしたとき、コマンドラインからConcourseインスタンスを管理できるように、flyコマンドラインツールをサーバーにインストールしました。 ただし、日常的に使用する場合は、通常の開発ツールとソースコードが利用できるローカルシステムにflyバイナリのコピーをインストールする方が便利です。
サーバーのバージョンと一致するflyのローカルコピーを取得するには、WebブラウザーでConcourseインスタンスにアクセスします。
https://your_concourse_url
ログアウトしている場合、または現在パイプラインが構成されていない場合は、さまざまなプラットフォーム用のflyをダウンロードするためのリンクがウィンドウの中央に表示されます。
ログインしてパイプラインを構成している場合は、flyのダウンロードリンクが画面の右下隅に表示されます。
ローカルコンピュータのオペレーティングシステムを表すアイコンをクリックして、flyバイナリをダウンロードします。
次に、プラットフォーム固有の手順に従って、ローカルシステムにflyをセットアップします。
LinuxまたはmacOS
ローカルコンピュータがLinuxまたはmacOSを実行している場合は、適切なバイナリをダウンロードした後、次の手順に従ってください。
まず、ダウンロードしたバイナリを実行可能としてマークします。 ファイルを~/Downloadsディレクトリにダウンロードしたと想定されるため、必要に応じてダウンロード場所を調整します。
chmod +x ~/Downloads/fly
次に、次のように入力して、PATH内の場所にバイナリをインストールします。
sudo install ~/Downloads/fly /usr/local/bin
次のように入力して、実行可能ファイルが使用可能であることを確認できます。
fly --version
Output3.3.1
バージョンを表示できれば、flyは正常にインストールされています。
ウィンドウズ
ローカルコンピューターでWindowsを実行している場合は、キーボードの Windowsキーを押し、 powershell と入力して、ENTERを押します。
表示されるウィンドウで、次のように入力してbinフォルダーを作成します。
mkdir bin
次に、次のように入力して、fly.exeファイルをDownloadsフォルダーから新しいbinフォルダーに移動します。
mv Downloads/fly.exe bin
PowerShellプロファイルがすでに利用可能かどうかを確認します。
Test-Path $profile
応答がTrueの場合、すでにプロファイルがあります。
応答がFalseの場合は、次のように入力して作成する必要があります。
New-Item -path $profile -type file -force
Output
Directory: C:\User\Sammy\Documents\WindowsPowerShell
Mode LastWriteTime Length Name
---- ------------- ------ ----
-a---- 7/9/2017 5:46 PM 0 Microsoft.PowerShell_profile.ps1
プロファイルを作成したら、エディターで編集します。
notepad.exe $profile
エディタウィンドウ（プロファイルを作成する必要がある場合は空白になります）で、次の行を追加します。
Microsoft.PowerShell_profile.ps1
$env:path += ";C:\Users\Sammy\bin"
終了したら、ファイルを保存して閉じます。
次に、現在のユーザーの実行ポリシーを「RemoteSigned」に設定して、PowerShellがプロファイルを読み取れるようにします。
Set-ExecutionPolicy -scope CurrentUser RemoteSigned
最後に、次のように入力してPowerShellプロファイルを取得します。
. $profile
これで、fly.exe実行可能ファイルを任意の場所から呼び出すことができるようになります。 バイナリにそのバージョンを印刷させることにより、これをテストします。
fly.exe --version
Output3.3.1
このガイド全体を通して、Windowsコマンドと一致するように、flyコマンドの各インスタンスをfly.exeに置き換える必要があります。
Concourseサーバーでの認証
flyをインストールした後、リモートのConcourseサーバーにログインして、CI環境をローカルで管理できるようにします。 単一のflyバイナリを使用して、複数のConcourseサーバーに接続および管理できるため、コマンドは、コマンドの送信先サーバーを識別するためのラベルとして「ターゲット」と呼ばれる概念を使用します。
このガイドでは、Concourseサーバーのターゲット名として main を使用していますが、任意のターゲット名に置き換えることができます。 -cオプションの後に、https://プロトコル指定を含むConcourseサーバーのドメイン名を入力して、サーバーの場所を示します。
fly -t main login -c https://example.com
Concourseサーバーの/etc/concourse/web_environmentファイルで構成したユーザー名とパスワードを入力するように求められます。
Outputlogging in to team 'main' username: sammy password: target saved
認証が完了すると、flyツールは、~/.flyrcという構成ファイルを作成して、将来のコマンド用に資格情報を保存します。
注： Concourseのバージョンを後でアップグレードする場合は、次のように入力して、一致するバージョンのflyコマンドをインストールできます。
fly -t main sync
これにより、システムのflyバイナリが更新されますが、構成はそのまま残ります。
サンプルリポジトリのフォークとクローン作成
システムにflyが設定されたので、Concourseパイプラインのデモンストレーションに使用するリポジトリの設定に進むことができます。
Webブラウザーで、GitHubの「hellohapi」アプリケーションにアクセスします。これを例として使用します。 このアプリケーションは、Node.jsWebフレームワークであるHapi.js で記述された、いくつかのユニットテストと統合テストを備えた単純な「HelloWorld」プログラムです。
この例はさまざまな継続的インテグレーションシステムを示すために使用されているため、他のシステムのパイプラインを定義するために使用されるファイルに気付く場合があります。 Concourseの場合、リポジトリの独自のフォークに継続的インテグレーションパイプラインを作成します。
リポジトリのフォークを作成するには、GitHubにログインし、プロジェクトリポジトリに移動します。 アカウントのリポジトリのコピーを作成するには、右上隅にあるフォークボタンをクリックします。
GitHub組織のメンバーである場合、リポジトリをフォークする場所を尋ねられることがあります。 アカウントまたは組織を選択すると、リポジトリのコピーがアカウントに追加されます。
次に、ローカルコンピュータのターミナルで、ホームディレクトリに移動します。
cd $HOME
次のコマンドを使用して、リポジトリをローカルコンピューターに複製し、独自のGitHubユーザー名に置き換えます。
git clone [email protected]:your_github_user/hello_hapi
hello_hapiという新しいディレクトリがホームディレクトリに作成されます。 開始するには、新しいディレクトリを入力してください。
cd hello_hapi
このリポジトリ内のサンプルプロジェクトの継続的インテグレーションパイプラインを定義します。 変更を加える前に、Gitで新しいブランチを作成して切り替え、変更を分離することをお勧めします。
git checkout -b pipeline
OutputSwitched to a new branch 'pipeline'
作業する新しいブランチができたので、継続的インテグレーションパイプラインの定義を開始できます。
アプリケーションの継続的インテグレーションプロセスの設定
プロジェクトリポジトリ自体の中にパイプラインとそれに関連するすべてのファイルを定義します。 これにより、継続的インテグレーションプロセスが、テストするコードと常に同期していることが保証されます。
テストスイートは、testというディレクトリ内ですでに定義されています。 これには、1つの単体テストと2つの基本的な統合テストが含まれます。 テストを実行するコマンドは、scriptsオブジェクト内のtestという名前でpackage.jsonファイルに定義されています。 npmとNode.jsがインストールされている環境では、npm testと入力してテストを実行できます（npm installでプロジェクトの依存関係をインストールした後）。 これらは、パイプラインで複製する必要がある手順です。
開始するには、リポジトリ内にciというディレクトリを作成して、プロジェクトの継続的インテグレーションアセットを格納します。 また、パイプラインが参照する個々のタスク定義とタスクが呼び出すスクリプトを保持するために、ci/tasksとci/scriptsという2つのサブディレクトリを作成します。
次のように入力して、必要なディレクトリ構造を作成します。
mkdir -p ci/{tasks,scripts}
次に、Concourseが使用する個々のファイルの作成を開始できます。
パイプラインの定義
ciディレクトリ内にpipeline.ymlというファイルを作成し、テキストエディタで開きます（このガイドではnanoエディタを示しますが、テキストエディタを代わりに使用する必要がありますシステム）。 拡張子が示すように、ConcourseファイルはYAMLデータシリアル化形式を使用して定義されます。
nano ci/pipeline.yml
これで、パイプラインの設定を開始できます。
NPMキャッシュリソースタイプを定義する
ファイル内で、新しいリソースタイプを定義することから始めます。
ci / pipeline.yml
---
resource_types:
- name: npm-cache
type: docker-image
source:
repository: ymedlop/npm-cache-resource
tag: latest
継続的インテグレーションのプロセスをシステムを通過するデータから分離するために、Concourseはすべての状態情報をresourcesと呼ばれる抽象化にオフロードします。 リソースは、Concourseが情報をプルしたりプッシュしたりするために使用できるデータの外部ソースです。 これは、すべてのデータが継続的インテグレーションシステムに入る方法であり、すべてのデータがジョブ間で共有される方法です。 Concourseは、ジョブ間で内部的に状態を保存または渡すためのメカニズムを提供しません。
resource_types 見出しを使用すると、電子メール通知、Twitter統合、RSSフィードなど、パイプラインで使用できる新しい種類のリソースを定義できます。 定義している新しいリソースタイプは、Concourseに npm-cache-resource の使用方法を指示します。これは、ConcourseがNode.jsプロジェクトの依存関係をインストールし、ジョブ間で共有できるようにするDockerイメージとして提供されるリソースです。 。
リポジトリとキャッシングリソースを定義する
次に、パイプラインの実際のリソースを定義する必要があります。
ci / pipeline.yml
. . .
resources:
- name: hello_hapi
type: git
source: &repo-source
uri: https://github.com/your_github_user/hello_hapi
branch: master
- name: dependency-cache
type: npm-cache
source:
<<: *repo-source
paths:
- package.json
このセクションでは、ConcourseCIジョブがタスクを完了するために必要な2つのリソースを定義します。 Concourseは、リソース定義を使用して、アップストリームシステムの変更を監視し、ジョブで必要なときにリソースをプルダウンする方法を理解します。 デフォルトでは、Concourseは各リソースの新しいバージョンを1分に1回チェックします。 「トリガー」オプションが設定されているリソースを必要とするジョブは、新しいバージョンが利用可能になると、自動的に新しいビルドを開始します。
最初のリソースは、GitHubのhello_hapiリポジトリのフォークを表します。 「source」行には、「repo-source」と呼ばれる YAMLアンカーが含まれており、将来の参照用に要素にラベルを付けます。 これにより、要素のコンテンツ（「uri」および「branch」の定義）をドキュメントの後半の別の場所に含めることができます。
「dependency-cache」と呼ばれる2番目のリソースは、プロジェクトの依存関係をダウンロードするために定義した「npm-cache」リソースタイプを使用します。 このリソースの「ソース」仕様では、<<: *repo-source行を使用して、&repo-sourceアンカーが指す要素をreferenceおよびextendします。 これにより、URIとブランチの設定がアプリケーションリポジトリリソースからこの2番目のリソースに挿入されます。 「パス」と呼ばれる追加の要素は、プロジェクトの依存関係が定義されているpackage.jsonファイルを指します。
依存関係の収集とテストのジョブを定義する
最後に、Concourse jobsを使用して実際の継続的インテグレーションプロセスを定義します。
ci / pipeline.yml
. . .
jobs:
- name: Install dependencies
plan:
- get: hello_hapi
trigger: true
- get: dependency-cache
- name: Run tests
plan:
- get: hello_hapi
trigger: true
passed: [Install dependencies]
- get: dependency-cache
passed: [Install dependencies]
- task: run the test suite
file: hello_hapi/ci/tasks/run_tests.yml
このセクションでは、名前と計画で構成される2つのジョブを定義します。 次に、各プランには「get」要素と「task」要素が含まれています。 task 項目はアクションの実行方法を指定し、get項目はタスクのリソース依存関係を示します。
最初のジョブにはタスクステートメントがありません。 これは少し珍しいことですが、それが何をしているのか、そしてそれをどのように使用できるのかを見ると理にかなっています。 最初のgetステートメントはhello_hapiリソースを必要とし、trigger: trueオプションを指定します。 これは、hello_hapiリポジトリで新しいコミットが検出されるたびに、リポジトリを自動的にフェッチし、このジョブの新しいビルドを開始するようにConcourseに指示します。
最初のジョブの2番目のgetステートメント（get: dependency-cache）には、プロジェクトのNode.js依存関係をダウンロードしてキャッシュする定義済みのリソースが必要です。 このステートメントは、package.jsonファイルにある要件を評価し、それらをダウンロードします。 このジョブにタスクが定義されていない場合、他のアクションは実行されませんが、ダウンロードされた依存関係は後続のジョブで使用できます。
注：この特定の例では、追加のジョブが1つしかないため、Node.jsの依存関係を独立したステップとしてキャッシュする利点は完全には実現されていません（テストジョブにgetステートメントを追加します。依存関係をダウンロードするには、以下で十分です）。 ただし、Node.jsでのほとんどすべての作業にはプロジェクトの依存関係が必要であるため、並行して実行できる可能性のある個別のジョブがある場合、個別の依存関係キャッシュの利点がより明確になります。
2番目のジョブ（name: Run tests）は、1つの顕著な違いを除いて、同じ依存関係を宣言することから始まります。 「passed」制約により、getステートメントは、パイプラインの前のステップを正常に通過したリソースのみに一致します。 これは、パイプラインプロセスをチェーン化するためにジョブ間の依存関係が形成される方法です。
getステートメントの後に、「テストスイートの実行」と呼ばれるタスクが定義されます。 インラインで完了するためのステップを定義するのではなく、フェッチしたリポジトリ内のファイルから定義をプルするようにConcourseに指示します。 次にこのファイルを作成します。
終了すると、完全なパイプラインは次のようになります。
ci / pipeline.yml
---
resource_types:
- name: npm-cache
type: docker-image
source:
repository: ymedlop/npm-cache-resource
tag: latest
resources:
- name: hello_hapi
type: git
source: &repo-source
uri: https://github.com/your_github_user/hello_hapi
branch: master
- name: dependency-cache
type: npm-cache
source:
<<: *repo-source
paths:
- package.json
jobs:
- name: Install dependencies
plan:
- get: hello_hapi
trigger: true
- get: dependency-cache
- name: Run tests
plan:
- get: hello_hapi
trigger: true
passed: [Install dependencies]
- get: dependency-cache
passed: [Install dependencies]
- task: run the test suite
file: hello_hapi/ci/tasks/run_tests.yml
終了したら、ファイルを保存して閉じます。
テストタスクの定義
パイプライン定義は継続的インテグレーションプロセスの構造を概説しましたが、実際のテストタスクの定義を別のファイルに延期しました。 タスクの抽出は、パイプライン定義を簡潔で読みやすくするのに役立ちますが、プロセス全体を理解するには、複数のファイルを読み取る必要があります。
ci/tasksディレクトリの下にあるrun_tests.ymlという名前の新しいファイルを開きます。
nano ci/tasks/run_tests.yml
タスクを定義するには、ワーカーに必要なオペレーティングシステムの種類を指定し、タスクの実行に使用するイメージを定義し、タスクが使用する入力または出力に名前を付け、実行するコマンドを指定する必要があります。
次の内容を貼り付けて、テストタスクを設定します。
ci / tasks / run_tests.yml
---
platform: linux
image_resource:
type: docker-image
source:
repository: node
tag: latest
inputs:
- name: hello_hapi
- name: dependency-cache
run:
path: hello_hapi/ci/scripts/run_tests.sh
上記の構成では、このタスクにLinuxワーカーが必要であることを指定しています。 Concourseサーバー自体は、追加の構成なしでこの要件を満たすことができます。
次に、ワーカーがタスクを実行するために使用する画像を示します。 独自のイメージタイプを作成して使用することもできますが、実際には、これはほとんどの場合Dockerイメージになります。 リポジトリはNode.jsアプリケーションであるため、適切なツールがすでにインストールされているため、テストを実行するために最新の「ノード」イメージを選択します。
コンコースタスクは、入力と出力を指定して、アクセスする必要のあるリソースと生成されるアーティファクトを示すことができます。 入力は、以前の「ジョブ」レベルでプルダウンされたリソースに対応します。 これらのリソースの内容は、タスクの実行中に操作できる最上位のディレクトリとしてタスク環境で利用できるようになります。 ここでは、アプリケーションリポジトリはhello_hapiディレクトリの下で利用可能になり、Node.jsの依存関係はdependency-cacheというディレクトリの下で利用可能になります。 実行ステップでは、タスクの開始時にファイルまたはディレクトリを予想される場所に移動し、タスクの終了時に出力の場所にアーティファクトを配置する必要がある場合があります。
最後に、 run アイテムは、実行するコマンドへのpathをリストします。 各タスクは引数を持つ単一のコマンドのみであるため、bash文字列を作成することでコマンドをインラインで作成することは可能ですが、タスクをスクリプトファイルにポイントする方が一般的です。 この場合、hello_hapi/ci/scripts/run_tests.shにあるhello_hapi入力ディレクトリのスクリプトを指します。 次に、このスクリプトを作成します。
終了したら、ファイルを保存して閉じます。
テストスクリプトの定義
最後に、タスクが実行するスクリプトを作成する必要があります。 ci/scripts/run_tests.shにあるrun_tests.shという名前の新しいファイルを開きます。
nano ci/scripts/run_tests.sh
このスクリプトは、テスト環境の入力を操作して、アイテムを正しい場所に移動します。 次に、npm testを実行して、リポジトリで定義されたテストスイートを実行します。
以下を新しいファイルに貼り付けます。
ci / scripts / run_tests.sh
#!/usr/bin/env bash set -e -u -x mv dependency-cache/node_modules hello_hapi cd hello_hapi && npm test
まず、このスクリプトはDockerコンテナーのbashインタープリターによって実行される必要があることを示します。 setオプションは、シェルのデフォルトの動作を変更して、エラーまたは未設定の変数によってスクリプトの実行を停止し、実行時に各コマンドを出力します。 これらは、スクリプトをより安全にし、デバッグ目的での可視性を高めるのに役立ちます。
最初に実行するコマンドは、node_modulesディレクトリにあるキャッシュされた依存関係をdependency-cacheディレクトリ内からhello_hapiディレクトリに移動します。 これらのディレクトリは、タスク定義の入力として指定したため、両方とも使用可能であることを忘れないでください。 この新しい場所は、npmが必要なダウンロードされた依存関係を探す場所です。
その後、アプリケーションリポジトリに移動し、npm testを実行して、定義されたテストスイートを実行します。
終了したら、ファイルを保存して閉じます。
先に進む前に、新しいスクリプトを実行可能としてマークして、直接実行できるようにします。
chmod +x ci/scripts/run_tests.sh
これで、パイプラインと関連するすべてのファイルが定義されました。
コンコースでのパイプラインの設定
pipelineブランチをmainにマージしてGitHubにプッシュする前に、パイプラインをConcourseにロードする必要があります。 Concourseは、リポジトリで新しいコミットを監視し、変更が検出されたときに継続的インテグレーション手順を実行します。
パイプラインを手動でロードする必要がありますが、Concourseがパイプラインを実行すると、リポジトリ内のディレクトリからタスクとスクリプトが読み取られます。 パイプライン自体への変更を有効にするには、Concourseに再ロードする必要がありますが、すべてをインラインで定義しなかったため、タスクまたはスクリプトへの変更は、コミットの一部としてアップロードされたときに自動的に通知されます。
新しいパイプラインを設定するには、set-pipelineアクションを使用してflyコマンドでConcourseサーバーをターゲットにします。 -pオプションを使用して新しいパイプラインの名前を渡し、-cオプションを使用してパイプライン構成ファイルを渡す必要があります。
fly -t main set-pipeline -p hello_hapi -c ci/pipeline.yml
続行する前に、構成を確認するように求められます。 y と入力し、ENTERを押します。
Output. . . apply configuration? [yN]: y pipeline created! you can view your pipeline here: https://example.com/teams/main/pipelines/hello_hapi the pipeline is currently paused. to unpause, either: - run the unpause-pipeline command - click play next to the pipeline in the web ui
出力が示すように、パイプラインは受け入れられましたが、現在一時停止されています。 flyまたはWebUIのいずれかを使用してパイプラインの一時停止を解除できます。 WebUIを使用します。
Webブラウザーで、Concourseサーバーにアクセスしてログインします。 新しいパイプラインが視覚的に定義されていることがわかります。
保留中のジョブは灰色のボックスで表され、リソースは小さくて暗いブロックです。 リソースの変更によってトリガーされたジョブは実線で接続され、トリガーされていないリソースは破線を使用します。 ジョブのoutを流れるリソースは、passed制約が次のジョブに設定されていることを示します。
青いヘッダーは、パイプラインが現在一時停止していることを示します。 左上のメニューアイコン（3本の横線）をクリックしてメニューを開きます。 パイプラインのエントリが表示されます（パイプラインが表示されていない場合は、ログアウトしてから再度ログインする必要があります）。 パイプラインの横にある青いplayアイコンをクリックして、一時停止を解除します。
これでパイプラインの一時停止が解除され、動作を開始します。
最初は、さまざまなリソースとジョブがオレンジ色に変わり、エラーが発生したことを示している場合があります。 これは、さまざまなDockerイメージをダウンロードする必要があり、タスクファイルとスクリプトファイルを使用できるようにするために、pipelineブランチをリポジトリのmainブランチにマージする必要があるためです。
Gitへの変更のコミット
継続的インテグレーションプロセスが定義されたので、それをgitリポジトリにコミットし、Concourseに追加できます。
次のように入力して、新しいciディレクトリをステージング領域に追加します。
git add ci
ステータスを確認して、コミットするファイルを確認します。
git status
OutputOn branch pipeline
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: ci/pipeline.yml
new file: ci/scripts/run_tests.sh
new file: ci/tasks/run_tests.yml
次のように入力して、変更をコミットします。
git commit -m 'Add Concourse pipeline'
これで、変更がpipelineブランチにコミットされます。 ブランチを切り替えてマージすることで、ブランチをmasterブランチにマージして戻すことができます。
git checkout master git merge pipeline
次に、新しい変更を加えたmasterブランチをGitHubにプッシュします。
git push origin master
コミットは60秒以内に新しいビルドを開始し、Concourseは変更をプルダウンした後、パイプラインタスクとスクリプトにアクセスできるようになります。
新しいビルドの表示
Concourse Web UIに戻ると、次の1分以内に新しいビルドがパイプラインを介して進行し始めます。
黄色のアウトラインは、ジョブが現在進行中であることを示します。 進行状況を監視するには、テストの実行ジョブをクリックして、現在の出力を確認します。 ジョブが完了すると、完全な出力が利用可能になり、ジョブが緑色に変わります。
ホームアイコンをクリックして、パイプラインのメイン画面に戻ります。 各ジョブの緑色のステータスは、最新のコミットがパイプラインのすべてのステージを通過したことを示します。
パイプラインは引き続きリポジトリを監視し、変更がコミットされると自動的に新しいテストを実行します。
結論
このガイドでは、リポジトリの変更を自動的に監視するようにConcourseパイプラインを設定します。 変更が検出されると、Concourseはリポジトリの最新バージョンをプルダウンし、Dockerコンテナを使用してプロジェクトの依存関係をインストールしてキャッシュします。 次に、ビルドはテスト段階に進み、依存関係がコピーされ、リポジトリのテストスイートが実行されて、重大な変更が導入されたかどうかが確認されます。
Concourseは、分離されたテスト手順を定義し、それらをリポジトリ自体に保存するための多くの柔軟性と能力を提供します。 Concourseを独自のプロジェクトに活用する方法について詳しく知りたい場合は、公式ドキュメントを確認してください。
