前書き
Concourse CIは、構成可能な宣言構文でテストパイプラインを自動化するように設計された、最新のスケーラブルな継続的統合システムです。 以前のガイドでは、https://www.digitalocean.com/community/tutorials/how-to-install-concourse-ci-on-ubuntu-16-04 [Ubuntu 16.04サーバーにインストールされたConcourse]およびhttps:// www.digitalocean.com/community/tutorials/how-to-secure-concourse-ci-with-ssl-using-nginx-on-ubuntu-16-04[Let’s EncryptのSSL証明書でWeb UIを保護]。
このガイドでは、新しい変更がリポジトリにコミットされたときにConcourseを使用してプロジェクトのテストスイートを自動的に実行する方法を示します。 デモのために、Node.js Webフレームワークであるhttps://hapijs.com/[Hapi.js]で記述された「hello world」アプリケーション用の継続的統合パイプラインを構成します。
ビルド手順とテスト手順が関連付けられているコードと常に同期していることを確認するために、CI定義をアプリケーションリポジトリ自体に追加します。 その後、Concourseの「+ fly +」コマンドラインツールを使用してパイプラインをConcourseに読み込みます。 最後に、変更をリポジトリにプッシュし、より永続的に保存し、新しいCIワークフローで新しいテストを開始します。
前提条件
始める前に、少なくとも1GのRAM *を備えたUbuntu 16.04サーバーが必要です。 非ルートユーザーのセットアップ、Concourseのインストールと構成、Nginxのインストール、TLS / SSL証明書の取得、Concourse Web UIへの安全なリバースプロキシのセットアップを行うには、以下のガイドを完了してください。 Concourseサーバーを適切に保護するには、*ドメイン名*が必要です。
このチュートリアルでは、ほとんどの作業はConcourseサーバーではなくローカルコンピューターで完了します。 そのため、ローカルマシンでいくつかのツールを使用できるようにする必要もあります。 リポジトリ内のファイルを作成および変更するには、テキストエディターが必要になります(さまざまなオペレーティングシステムで見られる例には、 + nano +
、 + vim +
、TextEdit、Sublime Text、Atom、またはメモ帳があります)。 また、ローカルシステムにGitをインストールしてセットアップする必要があります。これは、https://www.digitalocean.com/community/tutorials/contributing-to-open-source-getting-started-with-に従って実行できます。 git [オープンソースへの貢献:Git入門]ガイド。
Concourseサーバーをセットアップし、ローカルコンピューターにGitとテキストエディターをインストールしたら、以下に進みます。
Flyコマンドラインツールをローカルにインストールする
前提条件でサーバーにConcourseをインストールしたとき、コマンドラインからConcourseインスタンスを管理できるように、 `+ fly `コマンドラインツールをサーバーにインストールしました。 ただし、日常の使用では、通常の開発ツールとソースコードが利用可能なローカルシステムに ` fly +`バイナリのコピーをインストールする方が便利です。
サーバーのバージョンと一致する「+ fly +」のローカルコピーを取得するには、WebブラウザーでConcourseインスタンスにアクセスします。
https://
ログアウトしている場合、または現在設定されているパイプラインがない場合、さまざまなプラットフォーム用の `+ fly +`をダウンロードするためのリンクがウィンドウの中央に表示されます。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/big_download_link.png [コンコースフライ大きなダウンロードリンク]
ログインしてパイプラインを設定している場合、画面の右下隅にある「+ fly +」のダウンロードリンクを利用できます。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/small_download_link.png [コンコースフライの小さなダウンロードリンク]
ローカルコンピューターのオペレーティングシステムを表すアイコンをクリックして、「+ 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を実行している場合は、キーボードの* Windowsキー*を押し、* powershell と入力して、 ENTER *を押します。
表示されるウィンドウで、次のように入力して「+ bin +」フォルダーを作成します。
mkdir bin
次に、次のように入力して、「+ Downloads」フォルダーから「+ fly.exe 」ファイルを新しい「 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 `をインストールしたら、CI環境をローカルで管理できるように、リモートConcourseサーバーにログインします。 単一の ` fly +`バイナリを使用して、複数のConcourseサーバーに接続して管理できるため、コマンドは、コマンドを送信するサーバーを識別するラベルとして「ターゲット」という概念を使用します。
このガイドでは、Concourseサーバーのターゲット名として* main *を使用していますが、任意のターゲット名に置き換えることができます。 サーバーの場所を示すために、「-c +」オプションの後に「 https:// +」プロトコル仕様で完全なConcourseサーバーのドメイン名を入力します。
fly -t main login -c https://
Concourseサーバー上の `+ / etc / concourse / web_environment +`ファイルで設定したユーザー名とパスワードを入力するよう求められます:
Outputlogging in to team 'main'
username: sammy
password:
target saved
認証が完了すると、「+ fly 」ツールは「〜/ .flyrc +」という設定ファイルを作成して、今後のコマンドの認証情報を保存します。
サンプルリポジトリのフォークとクローン作成
システムに `+ fly +`が設定されたので、Concourseパイプラインのデモンストレーションに使用するリポジトリの設定に移ります。
Webブラウザで、https://github.com/do-community/hello_hapi [GitHubの「hello hapi」アプリケーション]にアクセスします。これはサンプルとして使用します。 このアプリケーションは、Node.js Webフレームワークであるhttps://hapijs.com/[Hapi.js]で記述された、いくつかの単体テストと統合テストを備えたシンプルな「hello world」プログラムです。
この例は、さまざまな継続的統合システムのデモンストレーションに使用されるため、他のシステムのパイプラインを定義するために使用されるファイルに気付く場合があります。 Concourseの場合、リポジトリの独自の分岐に継続的統合パイプラインを作成します。
リポジトリのフォークを作成するには、GitHubにログインしてhttps://github.com/do-community/hello_hapi[project repository]に移動します。 アカウントのリポジトリのコピーを作成するには、右上隅の*フォーク*ボタンをクリックします。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/fork_repository.png [hello hapi fork repository]
GitHub組織のメンバーである場合、リポジトリの分岐先を尋ねられる場合があります。 アカウントまたは組織を選択すると、リポジトリのコピーがアカウントに追加されます。
次に、ローカルコンピューターのターミナルで、ホームディレクトリに移動します。
cd $HOME
次のコマンドを使用して、ローカルコンピューターにリポジトリを複製し、独自のGitHubユーザー名に置き換えます。
git clone [email protected]:/hello_hapi
ホームディレクトリに「+ hello_hapi +」という新しいディレクトリが作成されます。 新しいディレクトリを入力して開始します。
cd hello_hapi
このリポジトリ内のサンプルプロジェクトの継続的な統合パイプラインを定義します。 変更を行う前に、Gitで新しいブランチを作成して切り替え、変更を分離することをお勧めします。
git checkout -b pipeline
OutputSwitched to a new branch 'pipeline'
作業する新しいブランチができたので、継続的な統合パイプラインの定義を開始できます。
アプリケーションの継続的統合プロセスの設定
プロジェクトリポジトリ自体内でパイプラインとそれに関連するすべてのファイルを定義します。 これにより、継続的インテグレーションプロセスが、テスト対象のコードと常に同期していることが保証されます。
テストスイートは、 + test`という名前のディレクトリ内で既に定義されています。 1つの単体テストと2つの基本的な統合テストが含まれています。 テストを実行するコマンドは、 `+ script`オブジェクト内の
+ test`という名前の + package.json`ファイルで定義されます。 `+ npm +`とNode.jsがインストールされている環境では、(+ npm install + `でプロジェクトの依存関係をインストールした後)
+ npm test + `と入力してテストを実行できます。 これらは、パイプラインで複製する必要がある手順です。
開始するには、リポジトリ内に「+ ci 」というディレクトリを作成して、プロジェクトの継続的な統合アセットを格納します。 また、パイプラインが参照する個々のタスク定義とタスクが呼び出すスクリプトを保持するために、「 ci / tasks 」および「 ci / scripts +」という2つのサブディレクトリを作成します。
次のように入力して、必要なディレクトリ構造を作成します。
mkdir -p ci/{tasks,scripts}
次に、Concourseが使用する個々のファイルの作成を開始できます。
パイプラインの定義
テキストエディタで `+ ci `ディレクトリ内に ` pipeline.yml `というファイルを作成して開きます(このガイドでは ` nano +`エディタを表示しますが、システムの代わりにテキストエディタを使用する必要があります)。 拡張機能が示すように、Concourseファイルはhttp://www.yaml.org/[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に依存関係をインストールできるようにするDockerイメージとして提供されるリソースhttps://github.com/ymedlop/npm-cache-resource[npm-cache-resource]の使用方法をConcourseに指示します。 Node.jsプロジェクトを作成し、ジョブ間で共有します。
リポジトリとキャッシュリソースを定義する
次に、パイプラインの実際のリソースを定義する必要があります。
ci / pipeline.yml
. . .
resources:
- name: hello_hapi
type: git
source: &repo-source
uri: https://github.com//hello_hapi
branch: master
- name: dependency-cache
type: npm-cache
source:
<<: *repo-source
paths:
- package.json
このセクションでは、Concourse CIジョブがタスクを完了するために必要な2つのリソースを定義します。 Concourseは、リソース定義を使用して、アップストリームシステムの変更を監視し、ジョブが必要とするときにリソースをプルダウンする方法を理解します。 デフォルトでは、Concourseは1分ごとに新しいバージョンの各リソースをチェックします。 「トリガー」オプションが設定されているリソースを必要とするジョブは、新しいバージョンが利用可能になると、自動的に新しいビルドを開始します。
最初のリソースは、GitHubの `+ hello_hapi +`リポジトリのフォークを表します。 「ソース」行には、「repo-source」と呼ばれるhttp://www.yaml.org/spec/1.2/spec.html#id2785586[YAMLアンカー]が含まれており、今後の参照用に要素にラベルを付けます。 これにより、エレメントのコンテンツ(「uri」および「branch」の定義)をドキュメント内の別の場所に含めることができます。
「dependency-cache」と呼ばれる2番目のリソースは、プロジェクトの依存関係をダウンロードするために定義した「npm-cache」リソースタイプを使用します。 このリソースの「ソース」仕様では、 `&repo-source +`アンカーが指す要素を_reference_および_extend_するために、 ` <<:* repo-source `行を使用します。 これにより、アプリケーションリポジトリリソースからuriおよびブランチの設定がこの2番目のリソースに挿入されます。 「paths」と呼ばれる追加の要素は、プロジェクトの依存関係が定義されている ` 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 `オプションを指定します。 これにより、Concourseはリポジトリが自動的に取得され、 ` hello_hapi +`リポジトリで新しいコミットが検出されるたびにこのジョブの新しいビルドが開始されます。
最初のジョブの2番目のgetステートメント( + get:dependency-cache +
)には、プロジェクトのNode.js依存関係をダウンロードおよびキャッシュするために定義したリソースが必要です。 このステートメントは、 `+ package.json +`ファイルにある要件を評価してダウンロードします。 このジョブにタスクが定義されていない場合、他のアクションは実行されませんが、ダウンロードされた依存関係は後続のジョブで利用できます。
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//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
完了したら、ファイルを保存して閉じます。
テストタスクの定義
パイプラインの定義では継続的インテグレーションプロセスの構造を概説しましたが、実際のテストタスクを別のファイルに定義することは延期しました。 タスクを抽出すると、パイプライン定義が簡潔で読みやすくなりますが、プロセス全体を理解するには複数のファイルを読む必要があります。
`+ run_tests.yml `という名前の ` ci / tasks +`ディレクトリの下に新しいファイルを開きます:
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
これで、パイプラインとすべての関連ファイルが定義されました。
Concourseでパイプラインを設定する
`+ 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]:
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 +」またはWeb UIを使用してパイプラインの一時停止を解除できます。 Web UIを使用します。
Webブラウザで、Concourseサーバーにアクセスしてログインします。 視覚的に定義された新しいパイプラインが表示されるはずです。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/inactive_pipeline.png [コンコース非アクティブパイプライン]
保留中のジョブは灰色のボックスで表され、リソースは小さく暗いブロックです。 リソースの変更によってトリガーされたジョブは実線で接続され、トリガーされていないリソースは破線を使用します。 ジョブの_out_を流れるリソースは、次のジョブで「+ passed +」制約が設定されたことを示します。
青いヘッダーは、パイプラインが現在一時停止していることを示します。 メニューを開くには、左上隅の*メニューアイコン*(3本の水平線)をクリックします。 パイプラインのエントリが表示されます(パイプラインが表示されない場合は、ログアウトしてからログインし直す必要がある場合があります)。 一時停止を解除するには、パイプラインの横にある青色の*再生*アイコンをクリックします。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/unpause_pipeline.png [コンコースのパイプラインの一時停止解除]
これでパイプラインの一時停止が解除され、運用が開始されます。
最初は、さまざまなリソースとジョブがオレンジ色に変わり、エラーが発生したことを示します。 これは、さまざまなDockerイメージをダウンロードする必要があり、タスクおよびスクリプトファイルを使用可能にするために、リポジトリの `+ main `ブランチに ` pipeline +`ブランチをマージする必要があるためです。
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に戻ると、次の数分以内に新しいビルドがパイプラインを通じて進行し始めます。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/running_test.png [テストスイートを実行するコンコース]
黄色のアウトラインは、ジョブが現在進行中であることを示します。 進行状況を監視するには、[テストの実行]ジョブをクリックして、現在の出力を確認します。 ジョブが完了すると、完全な出力が利用可能になり、ジョブが緑色に変わります。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/successful_tests.png [コンコース成功テスト]
*ホームアイコン*をクリックして、メインパイプライン画面に戻ります。 各ジョブの緑のステータスは、最新のコミットがパイプラインのすべての段階を通過したことを示しています。
image:https://assets.digitalocean.com/articles/concourse_usage_1604/passed_all_jobs.png [コンコースはすべてのジョブに合格しました]
パイプラインは引き続きリポジトリを監視し、変更がコミットされると新しいテストを自動的に実行します。
結論
このガイドでは、リポジトリの変更を自動的に監視するConcourseパイプラインを設定します。 変更が検出されると、Concourseはリポジトリの最新バージョンをプルダウンし、Dockerコンテナーを使用してプロジェクトの依存関係をインストールおよびキャッシュします。 次に、ビルドはテスト段階に進み、依存関係がコピーされ、リポジトリのテストスイートが実行されて、重大な変更が導入されたかどうかが確認されます。
Concourseは、独立したテスト手順を定義してリポジトリ自体に保存するための柔軟性とパワーを提供します。 独自のプロジェクトにConcourseを活用する方法について詳しく知りたい場合は、https://concourse.ci/introduction.html [公式ドキュメントをご覧ください]。