序章

Concourse CI は、構成可能な宣言型構文を使用してパイプラインのテストを自動化するように設計された、最新のスケーラブルな継続的インテグレーションシステムです。 以前のガイドでは、Ubuntu16.04サーバーにConcourseをインストールし、Let’sEncryptのSSL証明書を使用してWebUIを保護しました。

このガイドでは、新しい変更がリポジトリにコミットされたときに、Concourseを使用してプロジェクトのテストスイートを自動的に実行する方法を示します。 実例を示すために、Node.jsWebフレームワークであるHapi.jsで記述された「helloworld」アプリケーションの継続的インテグレーションパイプラインを構成します。

ビルドとテストの手順が、関連付けられているコードと常に同期していることを確認するために、CI定義をアプリケーションリポジトリ自体に追加します。 その後、コンコースを使用します fly パイプラインをConcourseにロードするためのコマンドラインツール。 最後に、変更をリポジトリにプッシュバックして、変更をより永続的に保存し、新しいCIワークフローで新しいテストを開始します。

前提条件

始める前に、少なくとも1GのRAMを備えたUbuntu16.04サーバーが必要です。 次のガイドを完了して、root以外のユーザーを設定し、Concourseをインストールして構成し、Nginxをインストールし、TLS / SSL証明書を取得し、ConcourseWebUIへの安全なリバースプロキシを設定します。 Concourseサーバーを適切に保護するには、Concourseサーバーを指すドメイン名が必要です。

このチュートリアルでは、ほとんどの作業はConcourseサーバーではなくローカルコンピューターで完了します。 そのため、ローカルマシンでいくつかのツールが使用可能であることも確認する必要があります。 テキストエディタが必要になります（さまざまなオペレーティングシステムで見られるいくつかの例は次のとおりです。 nano, vim、TextEdit、Sublime Text、Atom、またはNotepad）を使用して、リポジトリ内のファイルを作成および変更します。 また、ローカルシステムにGitをインストールしてセットアップする必要があります。これは、オープンソースへの貢献：Gitの開始ガイドに従って行うことができます。

Concourseサーバーをセットアップし、Gitとテキストエディターをローカルコンピューターにインストールしたら、以下に進みます。

Flyコマンドラインツールをローカルにインストールする

前提条件でサーバーにConcourseをインストールしたときに、 fly コマンドラインツールをサーバーにインストールして、コマンドラインからConcourseインスタンスを管理できるようにします。 ただし、日常的に使用する場合は、のコピーをインストールする方が便利です。 fly 通常の開発ツールとソースコードが利用できるローカルシステム上のバイナリ。

のローカルコピーを取得するには fly サーバーのバージョンと一致する場合は、WebブラウザーでConcourseインスタンスにアクセスします。

https://your_concourse_url

ログアウトしている場合、またはパイプラインが現在構成されていない場合は、ダウンロードへのリンク fly さまざまなプラットフォームの場合、ウィンドウの中央に表示されます。

ログインしてパイプラインを構成している場合は、次のリンクをダウンロードしてください fly 画面の右下隅に表示されます。

ローカルコンピュータのオペレーティングシステムを表すアイコンをクリックして、 fly バイナリ。

次に、プラットフォーム固有の手順に従ってセットアップします fly ローカルシステムで。

LinuxまたはmacOS

ローカルコンピュータがLinuxまたはmacOSを実行している場合は、適切なバイナリをダウンロードした後、次の手順に従ってください。

まず、ダウンロードしたバイナリを実行可能としてマークします。 ファイルをにダウンロードしたと想定します ~/Downloads ディレクトリなので、必要に応じてダウンロード場所を調整します。

  1. chmod +x ~/Downloads/fly

次に、次のように入力して、PATH内の場所にバイナリをインストールします。

  1. sudo install ~/Downloads/fly /usr/local/bin

次のように入力して、実行可能ファイルが使用可能であることを確認できます。

  1. fly --version



Output
3.3.1

バージョンを表示できる場合は、 fly 正常にインストールされました。

ウィンドウズ

ローカルコンピューターでWindowsを実行している場合は、キーボードの Windowsキーを押し、 powershell と入力して、ENTERを押します。

表示されるウィンドウで、 bin 次のように入力してフォルダを作成します。

  1. mkdir bin

次に、 fly.exe あなたからのファイル Downloads 新しいフォルダに bin 次のように入力してフォルダを作成します。

  1. mv Downloads/fly.exe bin

PowerShellプロファイルがすでに利用可能かどうかを確認します。

  1. Test-Path $profile

応答が True、あなたはすでにプロフィールを持っています。

応答が False、次のように入力して作成する必要があります。

  1. 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

プロファイルを作成したら、エディターで編集します。

  1. notepad.exe $profile

エディタウィンドウ（プロファイルを作成する必要がある場合は空白になります）で、次の行を追加します。

Microsoft.PowerShell_profile.ps1
$env:path += ";C:\Users\Sammy\bin"

終了したら、ファイルを保存して閉じます。

次に、現在のユーザーの実行ポリシーを「RemoteSigned」に設定して、PowerShellがプロファイルを読み取れるようにします。

  1. Set-ExecutionPolicy -scope CurrentUser RemoteSigned

最後に、次のように入力してPowerShellプロファイルを取得します。

  1. . $profile

これで、 fly.exe 任意の場所から実行可能。 バイナリにそのバージョンを印刷させることにより、これをテストします。

  1. fly.exe --version



Output
3.3.1

このガイド全体を通して、の各インスタンスを置き換える必要があります fly でコマンド fly.exe Windowsコマンドと一致します。

Concourseサーバーでの認証

インストール後 fly、リモートのConcourseサーバーにログインして、CI環境をローカルで管理できるようにします。 独身者 fly バイナリは複数のConcourseサーバーに接続して管理するために使用できるため、コマンドは「ターゲット」と呼ばれる概念をラベルとして使用して、コマンドの送信先のサーバーを識別します。

このガイドでは、Concourseサーバーのターゲット名として main を使用していますが、任意のターゲット名に置き換えることができます。 Concourseサーバーのドメイン名を入力します。 https:// 後のプロトコル仕様 -c サーバーの場所を示すオプション：

  1. fly -t main login -c https://example.com

で設定したユーザー名とパスワードを入力するように求められます /etc/concourse/web_environment Concourseサーバー上のファイル：

Output
logging in to team 'main'

username: sammy
password: 

target saved

認証が完了すると、 fly ツールはと呼ばれる構成ファイルを作成します ~/.flyrc 将来のコマンドのためにクレデンシャルを保存します。

注：後でConcourseのバージョンをアップグレードする場合は、対応するバージョンのConcourseをインストールできます。 fly 次のように入力してコマンドを実行します。

  1. fly -t main sync

これにより、 fly 構成をそのままにして、システム上のバイナリ。

サンプルリポジトリのフォークとクローン作成

今、あなたは fly システムにセットアップしたら、Concourseパイプラインのデモンストレーションに使用するリポジトリのセットアップに進むことができます。

Webブラウザーで、GitHubの「hellohapi」アプリケーションにアクセスします。これを例として使用します。 このアプリケーションは、Node.jsWebフレームワークであるHapi.js で記述された、いくつかのユニットテストと統合テストを備えた単純な「HelloWorld」プログラムです。

この例はさまざまな継続的インテグレーションシステムを示すために使用されているため、他のシステムのパイプラインを定義するために使用されるファイルに気付く場合があります。 Concourseの場合、リポジトリの独自のフォークに継続的インテグレーションパイプラインを作成します。

リポジトリのフォークを作成するには、GitHubにログインし、プロジェクトリポジトリに移動します。 アカウントのリポジトリのコピーを作成するには、右上隅にあるフォークボタンをクリックします。

GitHub組織のメンバーである場合、リポジトリをフォークする場所を尋ねられることがあります。  アカウントまたは組織を選択すると、リポジトリのコピーがアカウントに追加されます。

次に、ローカルコンピュータのターミナルで、ホームディレクトリに移動します。

  1. cd $HOME

次のコマンドを使用して、リポジトリをローカルコンピューターに複製し、独自のGitHubユーザー名に置き換えます。

  1. git clone [email protected]:your_github_user/hello_hapi

と呼ばれる新しいディレクトリ hello_hapi ホームディレクトリに作成されます。 開始するには、新しいディレクトリを入力してください。

  1. cd hello_hapi

このリポジトリ内のサンプルプロジェクトの継続的インテグレーションパイプラインを定義します。 変更を加える前に、Gitで新しいブランチを作成して切り替え、変更を分離することをお勧めします。

  1. git checkout -b pipeline



Output
Switched to a new branch 'pipeline'

作業する新しいブランチができたので、継続的インテグレーションパイプラインの定義を開始できます。

アプリケーションの継続的インテグレーションプロセスの設定

プロジェクトリポジトリ自体の中にパイプラインとそれに関連するすべてのファイルを定義します。 これにより、継続的インテグレーションプロセスが、テストするコードと常に同期していることが保証されます。

テストスイートは、というディレクトリ内ですでに定義されています test. これには、1つの単体テストと2つの基本的な統合テストが含まれます。 テストを実行するコマンドは、 package.json 名前の下のファイル test 以内 scripts 物体。 のある環境で npm Node.jsがインストールされている場合は、次のように入力してテストを実行できます npm test （プロジェクトの依存関係をインストールした後 npm install). これらは、パイプラインで複製する必要がある手順です。

開始するには、というディレクトリを作成します ci プロジェクトの継続的インテグレーションアセットを格納するリポジトリ内。 また、という2つのサブディレクトリを作成します ci/tasks と ci/scripts パイプラインが参照する個々のタスク定義と、タスクが呼び出すスクリプトを保持します。

次のように入力して、必要なディレクトリ構造を作成します。

  1. mkdir -p ci/{tasks,scripts}

次に、Concourseが使用する個々のファイルの作成を開始できます。

パイプラインの定義

と呼ばれるファイルを作成して開きます pipeline.yml 以内 ci テキストエディタを使用したディレクトリ（ nano このガイドのエディタですが、システムの代わりにテキストエディタを使用する必要があります）。 拡張子が示すように、ConcourseファイルはYAMLデータシリアル化形式を使用して定義されます。

  1. 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回チェックします。 「トリガー」オプションが設定されているリソースを必要とするジョブは、新しいバージョンが利用可能になると、自動的に新しいビルドを開始します。

最初のリソースは、 hello_hapi GitHubのリポジトリ。 「source」行には、「repo-source」と呼ばれる YAMLアンカーが含まれており、将来の参照用に要素にラベルを付けます。 これにより、要素のコンテンツ（「uri」および「branch」の定義）をドキュメントの後半の別の場所に含めることができます。

「dependency-cache」と呼ばれる2番目のリソースは、プロジェクトの依存関係をダウンロードするために定義した「npm-cache」リソースタイプを使用します。 このリソースの「ソース」仕様では、 <<: *repo-source referenceおよびextendへの行 &repo-source アンカー。 これにより、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 オプション。 これにより、Concourseは、リポジトリで新しいコミットが検出されるたびに、リポジトリを自動的にフェッチし、このジョブの新しいビルドを開始するように指示されます。 hello_hapi リポジトリ。

最初のジョブの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:

  1. 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 にある入力ディレクトリ hello_hapi/ci/scripts/run_tests.sh. 次に、このスクリプトを作成します。

終了したら、ファイルを保存して閉じます。

テストスクリプトの定義

最後に、タスクが実行するスクリプトを作成する必要があります。 と呼ばれる新しいファイルを開きます run_tests.sh にあります ci/scripts/run_tests.sh:

  1. 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 通訳者。 The set オプションを使用すると、シェルのデフォルトの動作が変更され、エラーが発生したり、変数が設定解除されたりして、スクリプトの実行が停止し、実行時に各コマンドが出力されます。 これらは、スクリプトをより安全にし、デバッグ目的での可視性を高めるのに役立ちます。

最初に実行するコマンドは、キャッシュされた依存関係を移動します。 node_modules ディレクトリ、内から dependency-cache ディレクトリへの hello_hapi ディレクトリ。 これらのディレクトリは、タスク定義の入力として指定したため、両方とも使用可能であることを忘れないでください。 この新しい場所は npm 必要なダウンロードされた依存関係を探します。

その後、アプリケーションリポジトリに移動して実行します npm test 定義されたテストスイートを実行します。

終了したら、ファイルを保存して閉じます。

先に進む前に、新しいスクリプトを実行可能としてマークして、直接実行できるようにします。

  1. chmod +x ci/scripts/run_tests.sh

これで、パイプラインと関連するすべてのファイルが定義されました。

コンコースでのパイプラインの設定

マージする前に pipeline に分岐して戻る main それをGitHubにプッシュして、パイプラインをConcourseにロードする必要があります。  Concourseは、リポジトリで新しいコミットを監視し、変更が検出されたときに継続的インテグレーション手順を実行します。

パイプラインを手動でロードする必要がありますが、Concourseがパイプラインを実行すると、リポジトリ内のディレクトリからタスクとスクリプトが読み取られます。  パイプライン自体への変更を有効にするには、Concourseに再ロードする必要がありますが、すべてをインラインで定義しなかったため、タスクまたはスクリプトへの変更は、コミットの一部としてアップロードされたときに自動的に通知されます。

新しいパイプラインを設定するには、次を使用してflyコマンドでConcourseサーバーをターゲットにします。 set-pipeline アクション。 新しいパイプラインの名前を次のように渡す必要があります -p オプションを選択し、パイプライン構成ファイルを -c オプション：

  1. 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 次のように入力して、ディレクトリをステージング領域に移動します。

  1. git add ci

ステータスを確認して、コミットするファイルを確認します。

  1. git status



Output
On 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

次のように入力して、変更をコミットします。

  1. git commit -m 'Add Concourse pipeline'

変更は現在、 pipeline ブランチ。 ブランチをマージして、 master ブランチを切り替えてマージすることによるブランチ：

  1. git checkout master

  2. git merge pipeline

今、プッシュ master 新しい変更をGitHubにバックアップして分岐します。

  1. git push origin master

コミットは60秒以内に新しいビルドを開始し、Concourseは変更をプルダウンした後、パイプラインタスクとスクリプトにアクセスできるようになります。

新しいビルドの表示

Concourse Web UIに戻ると、次の1分以内に新しいビルドがパイプラインを介して進行し始めます。

黄色のアウトラインは、ジョブが現在進行中であることを示します。 進行状況を監視するには、テストの実行ジョブをクリックして、現在の出力を確認します。 ジョブが完了すると、完全な出力が利用可能になり、ジョブが緑色に変わります。

ホームアイコンをクリックして、パイプラインのメイン画面に戻ります。 各ジョブの緑色のステータスは、最新のコミットがパイプラインのすべてのステージを通過したことを示します。

パイプラインは引き続きリポジトリを監視し、変更がコミットされると自動的に新しいテストを実行します。

結論

このガイドでは、リポジトリの変更を自動的に監視するようにConcourseパイプラインを設定します。 変更が検出されると、Concourseはリポジトリの最新バージョンをプルダウンし、Dockerコンテナを使用してプロジェクトの依存関係をインストールしてキャッシュします。 次に、ビルドはテスト段階に進み、依存関係がコピーされ、リポジトリのテストスイートが実行されて、重大な変更が導入されたかどうかが確認されます。

Concourseは、分離されたテスト手順を定義し、それらをリポジトリ自体に保存するための多くの柔軟性と能力を提供します。 Concourseを独自のプロジェクトに活用する方法について詳しく知りたい場合は、公式ドキュメントを確認してください。