次の方法で共有

GitHub リポジトリをビルドする

  • [アーティクル]

Azure DevOps Services の

Azure Pipelines では、すべてのプル要求を自動的にビルドして検証し、GitHub リポジトリにコミットできます。 この記事では、GitHub と Azure Pipelines の間の統合を構成する方法について説明します。

GitHub とのパイプライン統合を初めて使用する場合は、「最初のパイプラインを作成する」の手順に従ってください。 GitHub と Azure Pipelines の統合の構成とカスタマイズの詳細については、この記事に戻ってください。

組織とユーザー

GitHub と Azure Pipelines は、よく統合された 2 つの独立したサービスです。 それぞれの組織とユーザー管理があります。 このセクションでは、GitHub から Azure Pipelines に組織とユーザーをレプリケートする方法について推奨事項を示します。

組織

GitHub の構造は、の組織と、リポジトリを含むユーザー アカウント で構成されています。 GitHub のドキュメント参照してください。

GitHub 組織構造

Azure DevOps の構造は、プロジェクトを含む 組織で構成されます。 「組織構造を計画する」を参照してください。

Azure DevOps 組織構造 を する

Azure DevOps は、次の方法で GitHub 構造を反映できます。

  • GitHub 組織またはユーザー アカウントの DevOps 組織
  • GitHub リポジトリの DevOps Projects

Azure DevOps にマップされた GitHub 構造体の

Azure DevOps で同じ構造を設定するには:

  1. GitHub 組織またはユーザー アカウントにちなんだ DevOps 組織を作成します。 それは https://dev.azure.com/your-organizationのようなURLを持つことになります.
  2. DevOps 組織で、リポジトリにちなんだプロジェクトを作成します。 https://dev.azure.com/your-organization/your-repositoryなどの URL が表示されます。
  3. DevOps プロジェクトで、GitHub 組織にちなんだパイプラインと、ビルドするリポジトリ (your-organization.your-repositoryなど) を作成します。 その後、どのリポジトリが使用されているかが明らかになります。

このパターンに従うと、GitHub リポジトリと Azure DevOps Projects の URL パスが一致します。 例えば：

サービス URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

ユーザー

GitHub ユーザーが Azure Pipelines に自動的にアクセスすることはありません。 Azure Pipelines は、GitHub ID を認識します。 このため、GitHub ID と電子メール アドレスを使用して、ビルドエラーや PR 検証エラーをユーザーに自動的に通知するように Azure Pipelines を構成する方法はありません。 GitHub ユーザーをレプリケートするには、Azure Pipelines で新しいユーザーを明示的に作成する必要があります。 新しいユーザーを作成したら、GitHub でアクセス許可を反映するように Azure DevOps でアクセス許可を構成できます。 DevOps ID を使用して DevOps で通知を構成することもできます。

GitHub 組織のロール

GitHub 組織のメンバー ロールは、https://github.com/orgs/your-organization/people にあります (your-organizationを置き換えます)。

DevOps 組織のメンバーのアクセス許可は、https://dev.azure.com/your-organization/_settings/security にあります (your-organizationを置き換えます)。

GitHub 組織のロールと、Azure DevOps 組織の同等のロールを次に示します。

GitHub 組織の役割 DevOps 組織に相当する
所有者 Project Collection Administrators のメンバー
課金マネージャー Project Collection Administrators のメンバー
メンバー Project Collection Valid Usersのメンバー。 既定では、メンバー グループには新しいプロジェクトを作成するためのアクセス許可がありません。 アクセス許可を変更するには、グループの Create new projects アクセス許可を Allowに設定するか、必要なアクセス許可を持つ新しいグループを作成します。

GitHub ユーザー アカウント ロール

GitHub ユーザー アカウントには、アカウントの所有権である 1 つのロールがあります。

DevOps 組織のメンバーのアクセス許可は、https://dev.azure.com/your-organization/_settings/security にあります (your-organizationを置き換えます)。

GitHub ユーザー アカウント ロールは、次のように DevOps 組織のアクセス許可にマップされます。

GitHub ユーザー アカウント ロール DevOps 組織に相当する
所有者 Project Collection Administrators のメンバー

GitHub リポジトリのアクセス許可

GitHub リポジトリのアクセス許可は、https://github.com/your-organization/your-repository/settings/collaboration にあります (your-organization と your-repositoryを置き換えます)。

DevOps プロジェクトのアクセス許可は、https://dev.azure.com/your-organization/your-project/_settings/security にあります (your-organization と your-projectを置き換えます)。

GitHub リポジトリと Azure DevOps Projects の間の同等のアクセス許可は次のとおりです。

GitHub リポジトリのアクセス許可 DevOps プロジェクトに相当する
管理者 Project Administrators のメンバー
書く Contributors のメンバー
読む Readers のメンバー

GitHub リポジトリがチームにアクセス許可を付与している場合は、Azure DevOps プロジェクト設定の Teams セクションで一致するチームを作成できます。 次に、ユーザーと同様に、上記のセキュリティ グループにチームを追加します。

パイプライン固有のアクセス許可

DevOps プロジェクト内の特定のパイプラインのアクセス許可をユーザーまたはチームに付与するには、次の手順に従います。

  1. プロジェクトの [パイプライン] ページ (たとえば、https://dev.azure.com/your-organization/your-project/_build) にアクセスします。
  2. 特定のアクセス許可を設定するパイプラインを選択します。
  3. '...' コンテキスト メニューから、[セキュリティ選択します。
  4. [追加 選択...特定のユーザー、チーム、またはグループを追加し、パイプラインのアクセス許可をカスタマイズ。

GitHub リポジトリへのアクセス

新しいパイプラインを作成する場合は、まず GitHub リポジトリを選択してから、そのリポジトリ内の YAML ファイルを選択します。 YAML ファイルが存在するリポジトリは、リポジトリ self 呼び出されます。 既定では、これはパイプラインによってビルドされるリポジトリです。

後で、別のリポジトリまたは複数のリポジトリをチェックアウトするようにパイプラインを構成できます。 これを行う方法については、マルチリポジトリチェックアウト を参照してください。

ビルドをトリガーし、ビルド中にコードをフェッチするには、Azure Pipelines にリポジトリへのアクセス権を付与する必要があります。

パイプラインの作成時に Azure Pipelines に GitHub リポジトリへのアクセス権を付与するための認証の種類は 3 つあります。

認証の種類 パイプラインは、次を使用して実行されます GitHub チェック で動作します
1. GitHub アプリの を する Azure Pipelines ID はい
2. OAuth を する 個人の GitHub ID いいえ
3. 個人用アクセス トークン (PAT) を する 個人の GitHub ID いいえ

GitHub アプリ認証

Azure Pipelines GitHub アプリは、継続的インテグレーション パイプラインに推奨される 認証の種類 です。 GitHub アカウントまたは組織に GitHub アプリをインストールすると、個人の GitHub ID を使用せずにパイプラインが実行されます。 ビルドと GitHub の状態の更新は、Azure Pipelines ID を使用して実行されます。 このアプリは、GitHub Checks と連携して、ビルド、テスト、コード カバレッジの結果を GitHub に表示します。

GitHub アプリを使用するには、一部またはすべてのリポジトリの GitHub 組織またはユーザー アカウントにインストールします。 GitHub アプリは、アプリの ホームページからインストールおよびアンインストールできます。

インストール後、リポジトリのパイプラインが作成されると、GitHub アプリは (OAuth ではなく) GitHub に対する Azure Pipelines の既定の認証方法になります。

GitHub 組織内のすべてのリポジトリに GitHub アプリをインストールする場合は、Azure Pipelines が大量の電子メールを送信することや、ユーザーに代わってパイプラインを自動的に設定することを心配する必要はありません。 ただし、アプリがすべてのリポジトリにインストールされている場合、アプリケーションで使用されるトークンは、プライベートリポジトリを含むすべてのリポジトリにアクセスできます。 セキュリティ上の理由から、組織レベルでプライベート リポジトリとパブリック リポジトリを分離することをお勧めします。 これは、プライベート リポジトリのないパブリック プロジェクト専用の組織を持つことを意味します。 何らかの理由で、すべてのリポジトリにアクセス権を使用する代わりに、同じ組織内にパブリック リポジトリとプライベート リポジトリが必要な場合は、アプリケーションがアクセスできるリポジトリを明示的に選択します。 これには管理者にとってより多くの作業が必要ですが、セキュリティ管理が向上します。

GitHub で必要なアクセス許可

Azure Pipelines GitHub アプリをインストールするには、GitHub 組織の所有者またはリポジトリ管理者である必要があります。さらに、継続的インテグレーションと pull request トリガーを使用して GitHub リポジトリのパイプラインを作成するには、必要な GitHub アクセス許可が構成されている必要があります。 それ以外の場合、パイプラインの作成時にリポジトリ リポジトリの一覧に 表示されません。 リポジトリの認証の種類と所有権に応じて、適切なアクセスが構成されていることを確認します。

  • リポジトリが個人用 GitHub アカウントにある場合は、個人用 GitHub アカウントに Azure Pipelines GitHub アプリをインストールします。Azure Pipelines でパイプラインを作成するときに、このリポジトリを一覧表示できます。

  • リポジトリが他のユーザーの個人用 GitHub アカウントにある場合、他のユーザーは自分の個人用 GitHub アカウントに Azure Pipelines GitHub アプリをインストールする必要があります。 リポジトリの設定の [コラボレーター] でコラボレーターとして追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。 完了したら、そのリポジトリのパイプラインを作成できます。

  • リポジトリが所有する GitHub 組織にある場合は、GitHub 組織に Azure Pipelines GitHub アプリをインストールします。 また、コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。

  • リポジトリが他のユーザーが所有する GitHub 組織にある場合、GitHub 組織の所有者またはリポジトリ管理者は、組織に Azure Pipelines GitHub アプリをインストールする必要があります。 コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。

GitHub アプリのアクセス許可

GitHub アプリは、インストール中に次のアクセス許可を要求します。

許可 Azure Pipelines でのアクセス許可の使用方法
コードへの書き込みアクセス Azure Pipelines は、意図的なアクションに基づいてのみ、GitHub リポジトリの選択したブランチに YAML ファイルをコミットすることで、パイプラインの作成を簡略化します。
メタデータへの読み取りアクセス Azure Pipelines は、ビルドの概要で、ビルドに関連付けられているリポジトリ、ブランチ、および問題を表示するための GitHub メタデータを取得します。
チェックへの読み取りと書き込みアクセス Azure Pipelines は、GitHub に表示される独自のビルド、テスト、コード カバレッジの結果を読み書きします。
プル要求への読み取りと書き込みアクセス Azure Pipelines は、意図的なアクションに基づいてのみ、GitHub リポジトリの選択したブランチにコミットされた YAML ファイルのプル要求を作成することで、パイプラインの作成を簡略化します。 パイプラインは、プル要求に関連付けられているビルドの概要に表示する要求メタデータを取得します。

GitHub アプリのインストールのトラブルシューティング

GitHub では、次のようなエラーが表示される場合があります。

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

これは、組織に対して GitHub アプリが既にインストールされている可能性があることを意味します。 組織内のリポジトリのパイプラインを作成すると、GitHub アプリが GitHub への接続に自動的に使用されます。

複数の Azure DevOps の組織とプロジェクトにパイプラインを作成する

GitHub アプリがインストールされると、さまざまな Azure DevOps 組織およびプロジェクト内の組織のリポジトリのパイプラインを作成できます。 ただし、複数の Azure DevOps 組織で 1 つのリポジトリのパイプラインを作成する場合、GitHub のコミットまたはプル要求によって最初の組織のパイプラインのみを自動的にトリガーできます。 手動またはスケジュールされたビルドは、セカンダリ Azure DevOps 組織でも可能です。

OAuth 認証

OAuth は、個人用 GitHub アカウントのリポジトリで使用を開始する最も簡単な認証の種類です。 GitHub の状態の更新は、個人の GitHub ID に代わって実行されます。 パイプラインが機能し続けるためには、リポジトリへのアクセスがアクティブなままである必要があります。 チェックなどの一部の GitHub 機能は OAuth では使用できず、GitHub アプリが必要です。

OAuth を使用するには、[パイプラインの作成時にリポジトリの一覧の下にある別の接続 を選択します。 次に、[ の承認] を選択して GitHub にサインインし、OAuth で承認します。 OAuth 接続は、後で使用するために Azure DevOps プロジェクトに保存され、作成されるパイプラインで使用されます。

GitHub で必要なアクセス許可

継続的インテグレーションと pull request トリガーを使用して GitHub リポジトリのパイプラインを作成するには、必要な GitHub アクセス許可が構成されている必要があります。 それ以外の場合、パイプラインの作成時にリポジトリ リポジトリの一覧に 表示されません。 リポジトリの認証の種類と所有権に応じて、適切なアクセスが構成されていることを確認します。

  • リポジトリが個人用 GitHub アカウントにある場合は、少なくとも 1 回は、個人用 GitHub アカウントの資格情報を使用して OAuth を使用して GitHub に対して認証を行います。 これは、Azure DevOps プロジェクト設定の [Pipelines > Service connections > New service connection > GitHub > Authorize] で行うことができます。 ここでの [アクセス許可] で、リポジトリへのアクセス権を Azure Pipelines に付与します。

  • リポジトリが他のユーザーの個人用 GitHub アカウントにある場合、少なくとも 1 回は、他のユーザーが個人用 GitHub アカウントの資格情報を使用して OAuth を使用して GitHub に対して認証を行う必要があります。 これは、Azure DevOps プロジェクト設定の [Pipelines > Service connections > New service connection > GitHub > Authorize] で行うことができます。 他のユーザーは、ここで「アクセス許可」の下にあるリポジトリへのアクセス権を Azure Pipelines に付与する必要があります。 リポジトリの設定の [コラボレーター] でコラボレーターとして追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。

  • リポジトリが所有する GitHub 組織にある場合は、少なくとも 1 回は、個人用 GitHub アカウントの資格情報を使用して OAuth を使用して GitHub に対して認証を行います。 これは、Azure DevOps プロジェクト設定の [Pipelines > Service connections > New service connection > GitHub > Authorize] で行うことができます。 ここで「組織アクセス」で、Azure Pipelines に組織へのアクセス権を付与します。 コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。

  • リポジトリが他のユーザーが所有する GitHub 組織にある場合、少なくとも 1 回は、GitHub 組織の所有者は、個人の GitHub アカウント資格情報を使用して OAuth を使用して GitHub に対して認証を行う必要があります。 これは、Azure DevOps プロジェクト設定の [Pipelines > Service connections > New service connection > GitHub > Authorize] で行うことができます。 組織の所有者は、ここで「組織アクセス」下の組織への Azure Pipelines アクセス権を付与する必要があります。 コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。

OAuth アクセスの取り消し

Azure Pipelines で OAuth を使用することを承認した後、後で OAuth を取り消して、それ以上使用できないようにするには、GitHub の設定で OAuth Apps アクセスします。 Azure DevOps プロジェクト設定で GitHub サービス接続の一覧から削除することもできます。

個人用アクセス トークン (PAT) 認証

の は OAuth と実質的に同じですが、Azure Pipelines に付与されるアクセス許可を制御できます。 ビルドと GitHub の状態の更新は、個人の GitHub ID に代わって実行されます。 ビルドが動作し続けるためには、リポジトリへのアクセスがアクティブなままである必要があります。

PAT を作成するには、GitHub の設定 個人用アクセス トークン にアクセスします。 必要なアクセス許可は、repo、admin:repo_hook、read:user、および user:emailです。 これらは、上記の OAuth を使用するときに必要なのと同じアクセス許可です。 生成された PAT をクリップボードにコピーし、Azure DevOps プロジェクト設定の新しい GitHub サービス接続 に貼り付けます。 今後の思い出として、サービス接続に GitHub ユーザー名の後に名前を付けます。 これは、後でパイプラインを作成するときに使用するために、Azure DevOps プロジェクトで使用できるようになります。

GitHub で必要なアクセス許可

継続的インテグレーションと pull request トリガーを使用して GitHub リポジトリのパイプラインを作成するには、必要な GitHub アクセス許可が構成されている必要があります。 それ以外の場合、パイプラインの作成時にリポジトリ リポジトリの一覧に 表示されません。 リポジトリの認証の種類と所有権に応じて、次のアクセスが構成されていることを確認します。

  • リポジトリが個人の GitHub アカウントにある場合、PAT には、、、、の個人用アクセス トークン必要なアクセス スコープが必要です。

  • リポジトリが他のユーザーの個人用 GitHub アカウントにある場合、PAT は、、、、および の個人用アクセス トークン必要なアクセス スコープを持っている必要があります。 リポジトリの設定の [コラボレーター] でコラボレーターとして追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。

  • リポジトリが所有する GitHub 組織にある場合、PAT は、、、、の個人用アクセス トークン必要なアクセス スコープを持っている必要があります。 コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。

  • リポジトリが他のユーザーが所有する GitHub 組織にある場合、PAT は、、、、および の個人用アクセス トークン必要なアクセス スコープを持っている必要があります。 コラボレーターとして追加するか、リポジトリの [コラボレーターとチーム] の下の設定にチームを追加する必要があります。 電子メールで送信されたリンクを使用して、招待をコラボレーターとして受け入れます。

PAT アクセスの取り消し

PAT の使用を Azure Pipelines に承認した後、後で PAT を削除し、それ以上使用できないようにするには、GitHub の設定で 個人用アクセス トークンにアクセスします。 Azure DevOps プロジェクト設定で GitHub サービス接続の一覧から削除することもできます。

CI トリガー

継続的インテグレーション (CI) トリガーを使用すると、指定したブランチに更新をプッシュしたり、指定したタグをプッシュしたりするたびに、パイプラインが実行されます。

azure DevOps sprint 227で導入された 暗黙的な YAML CI トリガー 設定を無効にする が有効になっていない限り、YAML パイプラインは既定ですべてのブランチ で CI トリガーを使用して構成されます。 暗黙的な YAML CI トリガー を無効にする設定は、組織レベルまたはプロジェクト レベルで構成できます。 暗黙的な YAML CI トリガー の無効化設定が有効になっている場合、YAML パイプラインに trigger セクションがない場合、YAML パイプラインの CI トリガーは有効になりません。 既定では、暗黙的な YAML CI トリガー を無効にすることはできません。

枝

簡単な構文を使用して、CI トリガーを取得するブランチを制御できます。

trigger:
- main
- releases/*

ブランチの完全な名前 (mainなど) またはワイルドカード (releases/*など) を指定できます。 ワイルドカード構文の詳細については、「ワイルドカード」を参照してください。

手記

変数 トリガーでは使用できません。変数は実行時に評価されます (トリガーの起動後)。

手記

テンプレート を使用して YAML ファイルを作成する場合は、パイプラインのメイン YAML ファイルでのみトリガーを指定できます。 テンプレート ファイルにトリガーを指定することはできません。

exclude または batchを使用するより複雑なトリガーの場合は、次の例に示すように完全な構文を使用する必要があります。

# specific branch build
trigger:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

上記の例では、変更が main またはリリース ブランチにプッシュされると、パイプラインがトリガーされます。 ただし、oldで始まるリリース ブランチに変更が加えられた場合はトリガーされません。

include 句を指定せずに exclude 句を指定する場合、include 句で * を指定することと同じです。

branches リストでブランチ名を指定するだけでなく、次の形式を使用してタグに基づいてトリガーを構成することもできます。

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

トリガーを指定しなかった場合、暗黙的な YAML CI トリガーの を無効にする設定が有効になっていない場合、既定値は次のように記述します。

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

大事な

トリガーを指定すると、既定の暗黙的なトリガーが置き換えられ、含まれるよう明示的に構成されているブランチへのプッシュのみがパイプラインをトリガーします。 インクルードは最初に処理され、次にそのリストから除外が削除されます。

CI 実行のバッチ処理

多くのチーム メンバーが頻繁に変更をアップロードしている場合は、開始する実行の数を減らすことができます。 batch を trueに設定すると、パイプラインが実行されているときに、システムは実行が完了するまで待機し、まだビルドされていないすべての変更で別の実行を開始します。

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - main

手記

batch は、リポジトリ リソース トリガーではサポートされていません。

この例を明確にするために、main へのプッシュ A が原因で上記のパイプラインが実行されたとします。 そのパイプラインの実行中に、追加のプッシュ B し、リポジトリに C 発生します。 これらの更新プログラムは、新しい独立した実行をすぐに開始するわけではありません。 ただし、最初の実行が完了すると、その時点がバッチ処理され、新しい実行が開始されるまで、すべてのプッシュが実行されます。

手記

パイプラインに複数のジョブとステージがある場合でも、2 回目の実行を開始する前にすべてのジョブとステージを完了またはスキップすることで、最初の実行は終了状態に達する必要があります。 このため、複数のステージまたは承認があるパイプラインでこの機能を使用する場合は注意が必要です。 このような場合にビルドをバッチ処理する場合は、CI/CD プロセスを 2 つのパイプライン (ビルド用 (バッチ処理あり) とデプロイ用の 2 つのパイプラインに分割することをお勧めします。

パス

インクルードまたは除外するファイル パスを指定できます。

# specific path build
trigger:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

パスを指定するときは、Azure DevOps Server 2019.1 以前を使用している場合にトリガーするブランチを明示的に指定する必要があります。 パス フィルターのみでパイプラインをトリガーすることはできません。また、ブランチ フィルターも必要です。パス フィルターに一致する変更されたファイルは、ブランチ フィルターに一致するブランチからである必要があります。 Azure DevOps Server 2020 以降を使用している場合は、branches を省略して、パス フィルターと組み合わせてすべてのブランチでフィルター処理できます。

ワイルド カードはパス フィルターでサポートされています。 たとえば、src/app/**/myapp*に一致するすべてのパスを含めることができます。 パス フィルターを指定するときは、ワイルドカード文字 (**、*、または ?) を使用できます。

  • パスは、常にリポジトリのルートを基準にして指定されます。
  • パス フィルターを設定しない場合、リポジトリのルート フォルダーは既定で暗黙的に含まれます。
  • パスを除外する場合は、より深いフォルダーに修飾しない限り、パスを含めることはできません。 たとえば、/tools 除外する場合は、/tools/trigger-runs-on-these
  • パス フィルターの順序は関係ありません。
  • Git のパスでは、大文字と小文字が区別。 実際のフォルダーと同じケースを使用してください。
  • 変数は実行時 (トリガーの起動後) に評価されるため、パスに 変数を使用することはできません。

タグ

前のセクションで説明したように、branches リストでタグを指定するだけでなく、含めるタグまたは除外するタグを直接指定できます。

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

タグ トリガーを指定しない場合、既定では、タグはパイプラインをトリガーしません。

大事な

分岐フィルターと組み合わせてタグを指定すると、分岐フィルターが満たされているか、タグ フィルターが満たされている場合にトリガーが起動します。 たとえば、プッシュされたタグが分岐フィルターを満たす場合、プッシュが分岐フィルターを満たしていたため、タグがタグ フィルターによって除外された場合でもパイプラインがトリガーされます。

CI のオプトアウト

CI トリガーの無効化

trigger: noneを指定することで、CI トリガーを完全にオプトアウトできます。

# A pipeline with no CI trigger
trigger: none

大事な

ブランチに変更をプッシュすると、そのブランチ内の YAML ファイルが評価され、CI 実行を開始する必要があるかどうかを判断します。

個々のコミットの CI のスキップ

また、プッシュが通常トリガーするパイプラインの実行をスキップするように Azure Pipelines に指示することもできます。 プッシュの一部であるコミットのメッセージまたは説明に [skip ci] を含めるだけで、Azure Pipelines はこのプッシュの実行 CI をスキップします。 次のバリエーションのいずれかを使用することもできます。

  • [skip ci] または [ci skip]
  • skip-checks: true または skip-checks:true
  • [skip azurepipelines] または [azurepipelines skip]
  • [skip azpipelines] または [azpipelines skip]
  • [skip azp] または [azp skip]
  • ***NO_CI***

条件でのトリガーの種類の使用

実行を開始したトリガーの種類に応じて、パイプライン内のさまざまなステップ、ジョブ、またはステージを実行するのが一般的なシナリオです。 これは、システム変数 Build.Reasonを使用して行うことができます。 たとえば、次の条件をステップ、ジョブ、またはステージに追加して、PR 検証から除外します。

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

新しいブランチが作成されたときのトリガーの動作

同じリポジトリに対して複数のパイプラインを構成するのが一般的です。 たとえば、アプリのドキュメントをビルドするパイプラインと、ソース コードをビルドするためのパイプラインがあります。 これらの各パイプラインで、適切な分岐フィルターとパス フィルターを使用して CI トリガーを構成できます。 たとえば、docs フォルダーに更新をプッシュするときに 1 つのパイプラインをトリガーし、もう 1 つのパイプラインをアプリケーション コードにプッシュするときにトリガーすることができます。 このような場合は、新しいブランチが作成されたときにパイプラインがどのようにトリガーされるかを理解する必要があります。

新しいブランチ (ブランチ フィルターと一致する) をリポジトリにプッシュするときの動作を次に示します。

  • パイプラインにパス フィルターがある場合は、新しいブランチがそのパス フィルターに一致するファイルに変更を加えた場合にのみトリガーされます。
  • パイプラインにパス フィルターがない場合は、新しいブランチに変更がない場合でもトリガーされます。

ワイルドカード

分岐、タグ、またはパスを指定する場合は、正確な名前またはワイルドカードを使用できます。 ワイルドカード パターンを使用すると、* は 0 個以上の文字と一致し、? は 1 文字に一致します。

  • YAML パイプラインで * を使用してパターンを開始する場合は、"*-releases"のようにパターンを引用符で囲む必要があります。
  • ブランチとタグの場合:
    • ワイルドカードは、パターン内の任意の場所に表示できます。
  • パスの場合:
    • Azure DevOps Services を含む Azure DevOps Server 2022 以降では、パス パターン内の任意の場所にワイルドカードが表示される場合があり、* または ?を使用できます。
    • Azure DevOps Server 2020 以前では、最終的な文字として * を含めることができますが、ディレクトリ名を単独で指定する場合と何も変わりません。 パス フィルターの途中に 含め 、を使用しない場合があります。
trigger:
  branches:
    include:
    - main
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR トリガー

プル要求 (PR) トリガーは、指定されたターゲット ブランチのいずれかでプル要求が開かれるたびに、またはそのようなプル要求に対して更新が行われると、パイプラインを実行します。

枝

プル要求を検証するときに、ターゲット ブランチを指定できます。 たとえば、main と releases/*を対象とするプル要求を検証するには、次の pr トリガーを使用できます。

pr:
- main
- releases/*

この構成では、新しいプル要求が初めて作成されるときに、および pull request に対して行われたすべての更新の後に、新しい実行が開始されます。

ブランチの完全な名前 (mainなど) またはワイルドカード (releases/*など) を指定できます。

手記

変数 トリガーでは使用できません。変数は実行時に評価されます (トリガーの起動後)。

手記

テンプレート を使用して YAML ファイルを作成する場合は、パイプラインのメイン YAML ファイルでのみトリガーを指定できます。 テンプレート ファイルにトリガーを指定することはできません。

GitHub では、pull request の作成時に新しい ref が作成されます。 ref は、マージ コミットを指します。これは、プル要求のソースブランチとターゲット ブランチの間でマージされたコードです。 PR 検証パイプラインは、この 参照 が指すコミットをビルドします。 つまり、パイプラインの実行に使用される YAML ファイルは、ソースブランチとターゲット ブランチ間のマージでもあります。 その結果、プル要求のソース ブランチの YAML ファイルに加えた変更は、ターゲット ブランチの YAML ファイルによって定義された動作をオーバーライドできます。

YAML ファイルに pr トリガーが表示されない場合、次の pr トリガーを記述したかのように、すべてのブランチに対して pull request の検証が自動的に有効になります。 この構成は、プル要求が作成されたとき、およびアクティブなプル要求のソース ブランチにコミットが入ったときにビルドをトリガーします。

pr:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

大事な

ブランチのサブセットで pr トリガーを指定すると、更新がそれらのブランチにプッシュされたときにのみパイプラインがトリガーされます。

特定のブランチを除外する必要があるより複雑なトリガーの場合は、次の例に示すように完全な構文を使用する必要があります。 この例では、プル要求はターゲット main または releases/* が検証され、ブランチ releases/old* は除外されます。

# specific branch
pr:
  branches:
    include:
    - main
    - releases/*
    exclude:
    - releases/old*

パス

インクルードまたは除外するファイル パスを指定できます。 例えば：

# specific path
pr:
  branches:
    include:
    - main
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

のヒント:

  • Azure Pipelines は、パスの除外規則のために検証ビルドを実行しないことを決定したときに、中立状態を GitHub にポストバックします。 これにより、Azure Pipelines がその処理を完了したことを示す明確な指示が GitHub に提供されます。 詳細については、「ビルドがスキップされたときに、GitHub に中立状態を投稿する を参照してください。
  • ワイルドカードがパス フィルターでサポートされるようになりました。
  • パスは、常にリポジトリのルートを基準にして指定されます。
  • パス フィルターを設定しない場合、リポジトリのルート フォルダーは既定で暗黙的に含まれます。
  • パスを除外する場合は、より深いフォルダーに修飾しない限り、パスを含めることはできません。 たとえば、/tools 除外する場合は、/tools/trigger-runs-on-these
  • パス フィルターの順序は関係ありません。
  • Git のパスでは、大文字と小文字が区別。 実際のフォルダーと同じケースを使用してください。
  • 変数は実行時 (トリガーの起動後) に評価されるため、パスに 変数を使用することはできません。
  • Azure Pipelines は、パスの除外規則のために検証ビルドを実行しないことを決定したときに、中立状態を GitHub にポストバックします。

複数の PR 更新プログラム

PR の更新を増やして、同じ PR に対する進行中の検証の実行を取り消す必要があるかどうかを指定できます。 既定値は trueです。

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

ドラフト PR 検証

既定では、pull request トリガーは、レビューの準備ができている下書きプル要求とプル要求で発生します。 下書きプル要求の pull request トリガーを無効にするには、drafts プロパティを falseに設定します。

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

PR 検証のオプトアウト

pull request 検証を完全にオプトアウトするには、pr: noneを指定します。

# no PR triggers
pr: none

詳細については、YAML スキーマの PR トリガー を参照してください。

手記

pr トリガーが起動しない場合は、FAQのトラブルシューティング手順に従ってください。

オープン PR があり、そのソース ブランチに変更をプッシュすると、複数のパイプラインが実行される可能性があります。

  • PR のターゲット ブランチに PR トリガーがあるパイプラインは、マージ コミット (プル要求のソースブランチとターゲット ブランチ間のマージされたコード) で実行されます。メッセージまたは説明に [skip ci] (またはそのバリアント) が含まれるプッシュされたコミットが存在するかどうかに関係なく、
  • PR のソース ブランチへの変更によってトリガーされるパイプライン (メッセージまたは説明に (またはそのバリアント) が含まれる プッシュされたコミットが されていない場合)。 プッシュされたコミットが少なくとも 1 つ [skip ci]含まれている場合、パイプラインは実行されません。

最後に、PR をマージした後、マージ コミットのメッセージまたは説明に [skip ci] (またはそのバリアント) が含まれていない場合、Azure Pipelines はターゲット ブランチへのプッシュによってトリガーされる CI パイプラインを実行します。

保護されたブランチ

ブランチを対象とするコミットまたはプル要求ごとに検証ビルドを実行し、検証ビルドが成功するまでプル要求がマージされないようにすることもできます。

GitHub リポジトリの必須の検証ビルドを構成するには、その所有者、管理者ロールを持つコラボレーター、または書き込みロールを持つ GitHub 組織メンバーである必要があります。

  1. まず、リポジトリのパイプラインを作成し、その状態が GitHub に投稿されるように少なくとも 1 回ビルドして、GitHub にパイプラインの名前を認識させます。

  2. 次に、リポジトリの設定に 保護されたブランチを構成 GitHub のドキュメントに従います。

    状態チェックでは、状態チェックの一覧でパイプラインの名前 選択します。

    GitHub パイプラインの状態チェック

大事な

パイプラインがこの一覧に表示されない場合は、次のことを確認してください。

  • GitHub アプリ認証 使用している
  • パイプラインが過去 1 週間に少なくとも 1 回実行されている

外部ソースからの投稿

GitHub リポジトリがオープン ソースの場合は、Azure DevOps プロジェクトをパブリック に して、誰もがサインインせずにパイプラインのビルド結果、ログ、テスト結果を表示できるようにします。 組織外のユーザーがリポジトリをフォークしてプル要求を送信すると、それらのプル要求を自動的に検証するビルドの状態を表示できます。

外部ソースからの投稿を受け入れる際にパブリック プロジェクトで Azure Pipelines を使用する場合は、次の考慮事項に留意する必要があります。

アクセス制限

Azure DevOps パブリック プロジェクトでパイプラインを実行する場合は、次のアクセス制限に注意してください。

  • シークレット: 既定では、パイプラインに関連付けられているシークレットは、フォークの要求検証をプルするために使用できません。 フォークからのコントリビューションの検証 を参照してください。
  • プロジェクト間アクセス: Azure DevOps パブリック プロジェクト内のすべてのパイプラインは、プロジェクトに制限されたアクセス トークンで実行されます。 パブリック プロジェクト内のパイプラインは、ビルド成果物やテスト結果などのリソースにアクセスできるのはプロジェクト内のみで、Azure DevOps 組織の他のプロジェクトにはアクセスできません。
  • Azure Artifacts パッケージ: パイプラインが Azure Artifacts のパッケージにアクセスする必要がある場合は、パッケージ フィードにアクセスするために、Project Build Service アカウントへのアクセス許可を明示的に付与する必要があります。

フォークからの投稿

大事な

これらの設定は、パイプラインのセキュリティに影響します。

パイプラインを作成すると、リポジトリのフォークからのプル要求に対して自動的にトリガーされます。 この動作は、セキュリティに与える影響を慎重に考慮して変更できます。 この動作を有効または無効にするには:

  1. Azure DevOps プロジェクトに移動します。 パイプラインを選択し、パイプラインを見つけて、[編集] を選択します。
  2. [トリガー] タブを選択します。Pull request トリガーのを有効にした後、このリポジトリのフォークからプル要求をビルドする を有効または無効 チェック ボックスをオンまたはオフにします。

GitHub パイプラインでは、既定では、ビルド パイプラインに関連付けられているシークレットは、フォークの pull request ビルドでは使用できません。 これらのシークレットは、GitHub Enterprise Server パイプラインで既定で有効になっています。 シークレットには次のものが含まれます。

GitHub パイプラインでこの予防措置をバイパスするには、[フォーク ビルドでシークレットを使用できるようにする] チェック ボックス 有効にします。 この設定がセキュリティに与える影響に注意してください。

手記

フォーク ビルドを有効にしてシークレットにアクセスすると、Azure Pipelines は既定でフォーク ビルドに使用されるアクセス トークンを制限します。 通常のアクセス トークンよりも、開いているリソースへのアクセスが制限されています。 フォーク ビルドに通常のビルドと同じアクセス許可を付与するには、通常のビルドと同じアクセス許可 フォーク ビルド 設定を有効にします。

詳細については、「リポジトリの保護 - フォーク」を参照してください。

フォークされた GitHub リポジトリからプル要求をビルドする 制限 制御を使用して、パイプラインがフォークされた GitHub リポジトリから PR を構築する方法を一元的に定義できます。 これは、組織レベルとプロジェクト レベルで使用できます。 次のオプションを選択できます。

  • フォークされたリポジトリからのプル要求のビルドを無効にする
  • フォークされたリポジトリからプル要求を安全にビルドする
  • フォークされたリポジトリからプル要求をビルドするためのルールをカスタマイズする

フォークされた GitHub リポジトリからパイプラインが PR を構築する方法に関する一元化された制御設定のスクリーンショット。

Sprint 229以降では、パイプラインのセキュリティを向上させるために、Azure Pipelines では、フォークされた GitHub リポジトリからプル要求が自動的にビルドされなくなりました。 新しいプロジェクトと組織の場合、[フォークされた GitHub リポジトリからのプル要求のビルドを制限する ] 設定の既定値は、[フォークされたリポジトリからのプル要求のビルドを無効にする]。

フォークされたリポジトリからプル要求を安全にビルドする オプションを選択すると、すべてのパイプライン、組織、またはプロジェクト全体の は、フォークされたリポジトリの PR のビルドでシークレットを使用 できず、これらのビルドが通常のビルドと同じアクセス許可を持つ 、PR コメントによってトリガー 必要があります。 プロジェクトは、パイプラインでこのような PR を構築 許可しない を決定できます。

[ のカスタマイズ] オプションを選択すると、パイプライン設定を制限する方法を定義できます。 たとえば、PR がチーム 以外のメンバーと非共同作成者に属している場合に、フォークされた GitHub リポジトリから PR を構築するために、すべてのパイプラインにコメントが必要であることを確認できます。 ただし、そのようなビルドでシークレットを使用できるようにすることもできます。 プロジェクト 、パイプラインでこのような PR をビルドしたり、安全に構築したり、組織レベルで指定された設定よりもさらに制限の厳しい設定を行ったり しないことに決定できます。

既存の組織では、この制御はオフになっています。 2023 年 9 月以降、新しい組織は、既定で有効になっているフォークされたリポジトリからプル要求を安全に構築。

セキュリティに関する重要な考慮事項

GitHub ユーザーは、リポジトリをフォークして変更し、リポジトリに変更を提案するプル要求を作成できます。 このプル要求には、トリガーされたビルドの一部として実行する悪意のあるコードが含まれている可能性があります。 このようなコードは、次の方法で損害を引き起こす可能性があります。

  • パイプラインからシークレットをリークします。 このリスクを軽減するには、リポジトリがパブリックであるか、信頼されていないユーザーがビルドを自動的にトリガーするプル要求を送信できる場合は、[フォーク ビルドでシークレットを使用できるようにする] チェック ボックスをオンにしないでください。 このオプションは、既定では無効になっています。

  • エージェントを実行しているマシンを侵害して、他のパイプラインからコードまたはシークレットを盗みます。 これを軽減するには:

    • Microsoft がホストするエージェント プール を使用して、フォークからプル要求を作成します。 Microsoft がホストするエージェント マシンはビルドの完了後すぐに削除されるため、侵害されても永続的な影響はありません。

    • セルフホステッド エージェントを使用する必要がある場合は、リポジトリがプライベートであり、pull request 作成者が信頼できる場合を除き、シークレットを格納したり、同じエージェントでシークレットを使用する他のビルドやリリースを実行したりしないでください。

コメント トリガー

リポジトリコラボレーターは、手動でパイプラインを実行するために pull request にコメントできます。 これを行う一般的な理由を次に示します。

  • 変更を確認できるようになるまで、不明なユーザーからのプル要求を自動的に作成したくない場合があります。 チーム メンバーの 1 人が最初にコードを確認してから、パイプラインを実行する必要があります。 これは、フォークされたリポジトリから提供されたコードを構築する際のセキュリティ対策として一般的に使用されます。
  • オプションのテスト スイートまたは 1 つ以上の検証ビルドを実行できます。

コメント トリガーを有効にするには、次の 2 つの手順に従う必要があります。

  1. パイプラインの pull request トリガーを有効にし、ターゲット ブランチを除外していないことを確認します。
  2. Azure Pipelines Web ポータルで、パイプラインを編集し、[その他のアクション]、[ トリガー] の順に選択します。 次に、pull request 検証で、pull requestを作成する前にチーム メンバーのコメントを要求する を有効にします。
    • [すべての pull requests を選択して、pull request を作成する前にチーム メンバーのコメントを要求します。 このワークフローでは、チーム メンバーが pull request を確認し、pull request が安全であると見なされると、コメントを使用してビルドをトリガーします。
    • [チーム メンバー以外からの pull request のみを選択、チーム メンバー以外のメンバーが PR を行った場合にのみチーム メンバーのコメントを要求します。 このワークフローでは、チーム メンバーがビルドをトリガーするためにセカンダリ チーム メンバーのレビューを必要としません。

これら 2 つの変更により、チーム メンバー以外からの pull request でのみ が選択され、PR がチーム メンバーによって行われない限り、pull request 検証ビルドは自動的にトリガーされません。 '書き込み' アクセス許可を持つリポジトリの所有者とコラボレーターのみが、/AzurePipelines run または /AzurePipelines run <pipeline-name>で pull request にコメントすることでビルドをトリガーできます。

次のコマンドをコメントで Azure Pipelines に発行できます。

命令 結果
/AzurePipelines help サポートされているすべてのコマンドのヘルプを表示します。
/AzurePipelines help <command-name> 指定したコマンドのヘルプを表示します。
/AzurePipelines run このリポジトリに関連付けられている、トリガーがこのプル要求を除外しないすべてのパイプラインを実行します。
/AzurePipelines run <pipeline-name> トリガーがこのプル要求を除外しない限り、指定したパイプラインを実行します。

手記

簡潔にするために、/AzurePipelinesの代わりに /azp を使用してコメントすることができます。

大事な

これらのコマンドに対する応答は、パイプラインで Azure Pipelines GitHub Appを使用している場合にのみ、pull request ディスカッションに表示されます。

pull request コメント トリガーのトラブルシューティング

必要なリポジトリのアクセス許可を持っていても、パイプラインがコメントによってトリガーされない場合は、メンバーシップがリポジトリの組織内のパブリック されていることを確認するか、リポジトリコラボレーターとして自分を直接追加してください。 パイプラインは、直接コラボレーターであるか、直接コラボレーターであるチームに属していない限り、プライベート組織のメンバーを表示できません。 GitHub 組織のメンバーシップは、ここでプライベートからパブリックに変更できます (Your-Organization を組織名に置き換えます):https://github.com/orgs/Your-Organization/people。

情報の実行

情報実行では、Azure DevOps が YAML パイプラインのソース コードを取得できなかったことを示します。 ソース コードの取得は、プッシュされたコミットなどの外部イベントに応答して発生します。 また、内部トリガーに応答して発生します。たとえば、コードの変更があるかどうかを確認し、スケジュールされた実行を開始するかどうかなどです。 ソース コードの取得は複数の理由で失敗する可能性があります。多くの場合、Git リポジトリ プロバイダーによって調整が要求されます。 情報実行の存在は、必ずしも Azure DevOps がパイプラインを実行することを意味するとは限りません。

情報の実行は、次のスクリーンショットのようになります。

情報パイプラインの実行のスクリーンショット。

次の属性によって情報実行を認識できます。

  • 状態が Canceled
  • 期間は < 1s
  • 実行名には、次のいずれかのテキストが含まれています。
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • 通常、実行名には、YAML パイプラインの読み込みが失敗する原因となった BitBucket/GitHub エラーが含まれています
  • ステージ/ジョブ/ステップなし

情報実行の詳細について説明します。

チェックアウト

パイプラインがトリガーされると、Azure Pipelines は Azure Repos Git リポジトリからソース コードをプルします。 この動作のさまざまな側面を制御できます。

手記

パイプラインにチェックアウト ステップを含めると、次のコマンドが実行されます: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1。 これがニーズを満たしていない場合は、checkout: none して組み込みのチェックアウトを除外し、スクリプト タスクを使用して独自のチェックアウトを実行できます。

Git の優先バージョン

Windows エージェントには、Git の独自のコピーが付属しています。 付属のコピーを使用するのではなく、独自の Git を指定する場合は、System.PreferGitFromPath を trueに設定します。 この設定は、Windows 以外のエージェントでは常に当てはまります。

チェックアウト パス

1 つのリポジトリをチェックアウトする場合、既定では、ソース コードは sというディレクトリにチェックアウトされます。 YAML パイプラインの場合は、pathで checkout を指定することで、これを変更できます。 指定したパスは、$(Agent.BuildDirectory)に対する相対パスです。 たとえば、チェックアウト パスの値が mycustompath で、$(Agent.BuildDirectory) が C:\agent\_work\1場合、ソース コードは C:\agent\_work\1\mycustompathにチェックアウトされます。

複数の checkout ステップを使用し、複数のリポジトリをチェックアウトし、pathを使用してフォルダーを明示的に指定しない場合、各リポジトリはリポジトリの名前が付けられた s のサブフォルダーに配置されます。 たとえば、tools と codeという名前の 2 つのリポジトリをチェックアウトした場合、ソース コードは C:\agent\_work\1\s\tools および C:\agent\_work\1\s\codeにチェックアウトされます。

チェックアウトパスの値は $(Agent.BuildDirectory)より上のディレクトリレベルを上げるように設定することはできないので、path\..\anotherpath は有効なチェックアウトパス(つまり C:\agent\_work\1\anotherpath)になりますが、..\invalidpath のような値は設定されません(つまり C:\agent\_work\invalidpath)。

パイプラインの Checkout ステップで、path 設定を構成できます。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

サブモジュール

サブモジュールからファイルをダウンロードする場合は、パイプラインの Checkout ステップ 設定を構成できます。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

ビルド パイプラインでは、Git サブモジュールが次の場合に限りチェックアウトされます。

  • 認証されていない: 複製またはフェッチに必要な資格情報を持たないパブリックな認証されていないリポジトリ。

  • 認証された :

    • 上記で指定した Azure Repos Git リポジトリと同じプロジェクトに含まれています。 メイン リポジトリからソースを取得するためにエージェントによって使用されるのと同じ資格情報も、サブモジュールのソースを取得するために使用されます。

    • メイン リポジトリに対する相対 URL を使用して追加されます。 例えば

      • これはチェックアウトされます: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        この例では、サブモジュールは同じ Azure DevOps 組織内のリポジトリ (FabrikamFiber) を参照しますが、別のプロジェクト (FabrikamFiberProject) では参照します。 メイン リポジトリからソースを取得するためにエージェントによって使用されるのと同じ資格情報も、サブモジュールのソースを取得するために使用されます。 そのためには、ジョブ アクセス トークンが 2 番目のプロジェクトのリポジトリにアクセスできる必要があります。 上記のセクションで説明したようにジョブ アクセス トークンを制限した場合、これを行うことはできません。 (a) 2 番目のプロジェクトのプロジェクト ビルド サービス アカウントへのアクセスを明示的に許可するか、(b) 組織全体のプロジェクト スコープ トークンではなくコレクション スコープのアクセス トークンを使用して、ジョブ アクセス トークンが 2 番目のプロジェクトのリポジトリにアクセスできるようにします。 これらのオプションとそのセキュリティへの影響の詳細については、「アクセス リポジトリ、成果物、およびその他のリソースを参照してください。

      • これはチェックアウトされません:git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

チェックアウト サブモジュール オプションの使用に代わる方法

場合によっては、チェックアウト サブモジュール オプションを使用できない場合があります。 サブモジュールにアクセスするために別の資格情報セットが必要なシナリオがある場合があります。 これは、たとえば、メイン リポジトリとサブモジュール リポジトリが同じ Azure DevOps 組織に格納されていない場合や、ジョブ アクセス トークンが別のプロジェクトのリポジトリにアクセスできない場合などに発生する可能性があります。

チェックアウト サブモジュール オプションを使用できない場合は、代わりにカスタム スクリプト ステップを使用してサブモジュールをフェッチできます。 まず、個人用アクセス トークン (PAT) を取得し、pat:でプレフィックスを付けます。 次に、基本認証トークンを作成するために、このプレフィックス付き文字列 base64 エンコードを します。 最後に、次のスクリプトをパイプラインに追加します。

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

"<BASE64_ENCODED_STRING>" は、必ず Base64 でエンコードされた "pat:token" 文字列に置き換えてください。

プロジェクトまたはビルド パイプラインでシークレット変数を使用して、生成した基本認証トークンを格納します。 その変数を使用して、上記の Git コマンドでシークレットを設定します。

手記

Q: エージェントで Git 資格情報マネージャーを使用できないのはなぜですか?A: プライベート ビルド エージェントにインストールされている Git 資格情報マネージャーにサブモジュールの資格情報を格納することは、通常は有効ではありません。これは、サブモジュールが更新されるたびに資格情報を再入力するように資格情報マネージャーが求める場合があるためです。 これは、ユーザーの操作が不可能な場合、自動ビルドでは望ましくありません。

タグの同期

大事な

同期タグ機能は、Azure DevOps Server 2022.1 以降の Azure Repos Git でサポートされています。

チェックアウト手順では、Git リポジトリの内容をフェッチするときに、--tags オプションを使用します。 これにより、サーバーはすべてのタグと、それらのタグによって指されているすべてのオブジェクトをフェッチします。 これにより、特に多数のタグを持つ大規模なリポジトリがある場合に、パイプラインでタスクを実行する時間が長くなります。 さらに、チェックアウト ステップでは、シャロー フェッチ オプションを有効にした場合でもタグが同期されるため、その目的が失われる可能性があります。 Git リポジトリからフェッチまたはプルされるデータの量を減らすために、Microsoft はタグの同期動作を制御するためのチェックアウトの新しいオプションを追加しました。 このオプションは、クラシック パイプラインと YAML パイプラインの両方で使用できます。

リポジトリをチェックアウトするときにタグを同期するかどうかを YAML で構成するには、fetchTags プロパティを設定し、UI で 同期タグ 設定を構成します。

パイプラインの Checkout ステップで、fetchTags 設定を構成できます。

YAML で設定を構成するには、fetchTags プロパティを設定します。

steps:
- checkout: self
  fetchTags: true

パイプライン設定 UI の 同期タグ オプションを使用して、この設定を構成することもできます。

  1. YAML パイプラインを編集し、[その他のアクション]、[ トリガー] を選択します。

    その他のトリガー メニューのスクリーンショット。

  2. YAML選択し、[ソースの取得]を します。

    ソースの取得のスクリーンショット。

  3. 同期タグの 設定を構成します。

    同期タグの設定のスクリーンショット。

手記

checkout ステップで fetchTags を明示的に設定した場合、その設定はパイプライン設定 UI で構成された設定よりも優先されます。

既定の動作

  • 2022 年 9 月にリリースされた Azure DevOps sprint 209のリリース前に作成された既存のパイプラインの場合、タグの同期の既定値は、同期タグ オプションが追加される前の既存の動作 (true) と同じです。
  • Azure DevOps スプリント リリース 209 の後に作成された新しいパイプラインの場合、タグの同期の既定値は falseです。

手記

checkout ステップで fetchTags を明示的に設定した場合、その設定はパイプライン設定 UI で構成された設定よりも優先されます。

浅いフェッチ

履歴に戻ってダウンロードする距離を制限することもできます。 実質的にこれは git fetch --depth=nになります. リポジトリが大きい場合、このオプションを使用すると、ビルド パイプラインの効率が向上する可能性があります。 リポジトリが長い間使用されていて、サイズの大きい履歴がある場合は、リポジトリが大きくなる可能性があります。 また、大きなファイルを追加して後で削除した場合も大きくなる可能性があります。

大事な

2022 年 9 月の Azure DevOps スプリント 209 更新プログラムの後に作成された新しいパイプライン、シャロー フェッチ が既定で有効になり、深さが 1 で構成されています。 以前は、既定値はシャロー フェッチではありません。 パイプラインを確認するには、次のセクションで説明するように、パイプライン設定 UI で の簡易フェッチの 設定を表示します。

パイプラインの Checkout ステップで、fetchDepth 設定を構成できます。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

また、パイプライン設定 UI で [浅い深度] オプションを設定して、フェッチの深さを構成することもできます。

  1. YAML パイプラインを編集し、[その他のアクション]、[ トリガー] を選択します。

    その他のトリガー メニューのスクリーンショット。

  2. YAML選択し、[ソースの取得]を します。

    ソースの取得のスクリーンショット。

  3. の [簡易フェッチ] 設定を構成します。 シャロー フェッチ オフにしてシャロー フェッチを無効にするか、チェック ボックスをオンにして 深度 を入力してシャロー フェッチを有効にします。

    オプションのスクリーンショット。

手記

checkout ステップで fetchDepth を明示的に設定した場合、その設定はパイプライン設定 UI で構成された設定よりも優先されます。 fetchDepth: 0 設定すると、すべての履歴がフェッチされ、シャロー フェッチの 設定がオーバーライドされます。

このような場合、このオプションは、ネットワークリソースとストレージリソースを節約するのに役立ちます。 また、時間を節約することもできます。 時間が常に節約されるとは限らない理由は、状況によっては、サーバーが、指定した深さのためにダウンロードするコミットの計算に時間を費やす必要がある場合があるためです。

手記

パイプラインが開始されると、ビルドするブランチがコミット ID に解決されます。 次に、エージェントはブランチをフェッチし、目的のコミットをチェックアウトします。 ブランチがコミット ID に解決されてから、エージェントがチェックアウトを実行する間には、小さなウィンドウがあります。 ブランチが急速に更新され、シャロー フェッチに非常に小さな値を設定した場合、エージェントがチェックアウトしようとしたときにコミットが存在しない可能性があります。その場合は、シャロー フェッチの深度設定を増やします。

ソースを同期しない

新しいコミットのフェッチをスキップすることもできます。 このオプションは、次の場合に役立ちます。

  • 独自のカスタム オプションを使用して Git init、config、fetch を行います。

  • ビルド パイプラインを使用して、バージョン管理のコードに依存しない自動化 (一部のスクリプトなど) を実行します。

checkout: noneを設定することで、パイプラインの Checkout ステップで [ソース 同期しない] 設定を構成できます。

steps:
- checkout: none  # Don't sync sources

手記

このオプションを使用すると、エージェントはリポジトリをクリーンアップする Git コマンドの実行もスキップします。

クリーン ビルド

ビルドを実行する前に、セルフホステッド エージェントの作業ディレクトリをさまざまな形式でクリーニングできます。

一般に、セルフホステッド エージェントのパフォーマンスを向上させるには、リポジトリをクリーンアップしないでください。 この場合、最適なパフォーマンスを得るには、ビルドに使用しているタスクまたはツールの Clean オプションを無効にして、段階的にビルドしていることを確認します。

リポジトリをクリーンアップする必要がある場合 (たとえば、以前のビルドからの残余ファイルによる問題を回避するため)、オプションは以下のとおりです。

手記

新しいエージェントが毎回取得されるため、Microsoft でホストされるエージェント を使用している場合、クリーニングは有効ではありません。

パイプラインの Checkout ステップで、clean 設定を構成できます。

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

clean が true に設定されている場合、ビルド パイプラインは $(Build.SourcesDirectory)の変更を元に戻します。 具体的には、ソースをフェッチする前に、次の Git コマンドが実行されます。

git clean -ffdx
git reset --hard HEAD

その他のオプションについては、ジョブの workspace 設定を構成できます。

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

これにより、次のクリーン なオプションが提供されます。

  • 出力: 前のチェックアウト タスクで説明したクリーン設定と同じ操作に加えて、$(Build.BinariesDirectory)を削除して再作成します。 $(Build.ArtifactStagingDirectory) と $(Common.TestResultsDirectory) は、これらの設定に関係なく、すべてのビルドの前に常に削除および再作成されることに注意してください。

  • リソース: $(Build.SourcesDirectory)を削除して再作成します。 これにより、ビルドごとに新しいローカル Git リポジトリが初期化されます。

  • すべてのを :を削除して再作成します。 これにより、ビルドごとに新しいローカル Git リポジトリが初期化されます。

ラベル ソース

完成したビルドに含まれる各ファイルのバージョンをチームが簡単に識別できるように、ソース コード ファイルにラベルを付けることもできます。 また、ソース コードをすべてのビルドに対してラベル付けするか、成功したビルドに対してのみラベル付けするかを指定することもできます。

現在、この設定は YAML では構成できませんが、クラシック エディターでは構成できます。 YAML パイプラインを編集するときに、YAML エディター メニューから トリガー を選択することで、クラシック エディターにアクセスできます。

Git オプション (YAML) を構成します。

クラシック エディターから YAML選択し、[ソースの取得] タスク 選択し、そこで目的のプロパティを構成します。

クラシック エディターから、[YAML] > [ソースの取得] を選択します。

タグ形式 では、"All" のスコープを持つユーザー定義変数と定義済み変数を使用できます。例えば：

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

最初の 4 つの変数は定義済みです。 My.Variable は、変数タブで定義できます。

ビルド パイプラインでは、ソースに Git タグラベルが付けられます。

一部のビルド変数では、有効なラベルではない値が生成される場合があります。 たとえば、$(Build.RequestedFor) や $(Build.DefinitionName) などの変数には空白を含めることができます。 値に空白が含まれている場合、タグは作成されません。

ソースがビルド パイプラインによってタグ付けされると、Git ref refs/tags/{tag} を持つ成果物が完了したビルドに自動的に追加されます。 これにより、チームの追跡可能性が向上し、ビルドからビルドされたコードに簡単に移動できます。 タグはビルドによって生成されるため、ビルド成果物と見なされます。 手動またはアイテム保持ポリシーを使用してビルドを削除すると、タグも削除されます。

定義済みの変数

GitHub リポジトリを構築すると、定義済みの変数 のほとんどはジョブで使用できます。 ただし、Azure Pipelines は GitHub で更新を行うユーザーの ID を認識しないため、次の変数はユーザーの ID ではなくシステム ID に設定されます。

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

状態の更新

Azure Pipelines が GitHub にポストバックする状態には、基本的な状態と GitHub Check Runs の 2 種類があります。 GitHub チェック機能は、GitHub Apps でのみ使用できます。

パイプラインの状態は、GitHub UI のさまざまな場所に表示されます。

  • PR の場合は、[PR 会話] タブに表示されます。
  • 個々のコミットの場合、リポジトリのコミット タブのコミット時間の後に状態マークをポイントすると、それらのコミットが表示されます。

PAT または OAuth GitHub 接続

PAT または OAuth GitHub 接続を使用するパイプラインの場合、実行をトリガーしたコミット/PR に状態がポストバックされます。 GitHub 状態 API は、このような更新プログラムを投稿するために使用されます。 これらの状態には、パイプラインの状態 (失敗、成功)、ビルド パイプラインにリンクする URL、状態の簡単な説明など、限られた情報が含まれています。

PAT または OAuth GitHub 接続の状態は、実行レベルでのみ送信されます。 つまり、実行全体に対して 1 つの状態を更新できます。 1 回の実行に複数のジョブがある場合、ジョブごとに個別の状態を投稿することはできません。 ただし、複数のパイプラインで、同じコミットに個別の状態をポストできます。

GitHub のチェック

Azure Pipelines GitHub アプリを使用して設定されたパイプラインの場合、状態は GitHub チェックの形式でポストバックされます。 GitHub チェックを使用すると、パイプラインの状態とテスト、コード カバレッジ、エラーに関する詳細情報を送信できます。 GitHub Checks API は、見つけることができます。

GitHub アプリを使用するすべてのパイプラインについて、実行全体とその実行の各ジョブのチェックがポストバックされます。

GitHub では、PR/コミットに対して 1 つ以上のチェック実行が失敗した場合、3 つのオプションを使用できます。 個々のチェックを "再実行" するか、その PR/コミットで失敗したすべてのチェックを再実行するか、最初に成功したかどうかに関係なく、すべてのチェックを再実行するかを選択できます。

GitHub チェック 再実行する

実行の確認名の横にある [再実行] リンクをクリックすると、実行の確認を生成した実行が Azure Pipelines によって再試行されます。 結果の実行は同じ実行番号を持ち、最初のビルドと同じバージョンのソース コード、構成、および YAML ファイルを使用します。 最初の実行で失敗したジョブと依存するダウンストリーム ジョブのみが再度実行されます。 [失敗したすべてのチェックを再実行する] リンクをクリックすると、同じ効果が得られます。 これは、Azure Pipelines UI で [実行の再試行] をクリックした場合と同じ動作です。 [すべてのチェックを再実行する] をクリックすると、新しい実行番号で新しい実行が行われ、構成または YAML ファイルの変更が取得されます。

制限

  • パフォーマンスを最大限に高めるには、1 つのリポジトリに最大 50 個のパイプラインを使用することをお勧めします。 許容可能なパフォーマンスを得る場合は、1 つのリポジトリに最大 100 個のパイプラインを使用することをお勧めします。 リポジトリへのプッシュを処理するために必要な時間は、そのリポジトリ内のパイプラインの数に応じて増加します。 リポジトリへのプッシュが発生するたびに、Azure Pipelines では、そのリポジトリ内のすべての YAML パイプラインを読み込んで、実行する必要があるかどうかを判断する必要があります。また、各パイプラインを読み込むと、パフォーマンスの低下が発生します。 パフォーマンスの問題に加えて、1 つのリポジトリにパイプラインが多すぎると、Azure Pipelines が短時間で多すぎる要求を行う可能性があるため、GitHub 側で調整が発生する可能性があります。

  • を使用すると、 が拡張され、パイプラインに テンプレートが含まれる は、Azure Pipelines が GitHub API 要求を行う速度に影響を与え、GitHub 側での調整につながる可能性があります。 パイプラインを実行する前に、Azure Pipelines は完全な YAML コードを生成する必要があるため、すべてのテンプレート ファイルをフェッチする必要があります。

  • Azure Pipelines は、Azure DevOps ポータルのドロップダウン リストに最大 2,000 個のブランチを読み込みます。たとえば、[手動およびスケジュールされたビルドの既定の ブランチの 既定のブランチを選択 設定の場合や、パイプラインを手動で実行するときにブランチを選択する場合などです。

    一覧に目的のブランチが表示されない場合は、手動ビルドとスケジュールされたビルドの 既定のブランチ フィールドに、目的のブランチ名を手動で入力します。

    省略記号をクリックして [ブランチ 選択] ダイアログを開き、ドロップダウン リストから有効なブランチを選択せずにダイアログを閉じると、[一部の設定には注意が必要な メッセージが表示される場合があります。この設定は、手動ビルドとスケジュールされたビルド既定のブランチの下 メッセージ 必要があります。 このメッセージを回避するには、パイプラインを再度開き、手動ビルドとスケジュールされたビルドの Default ブランチ フィールドに直接名前を入力します。

FAQ

GitHub 統合に関連する問題は、次のカテゴリに分類されます。

  • 接続の種類: パイプラインを GitHub に接続するために使用している接続の種類がわからない場合があります。
  • 失敗したトリガー: リポジトリに更新をプッシュするときにパイプラインがトリガーされません。
  • チェックアウト失敗: パイプラインがトリガーされていますが、チェックアウト手順で失敗します。
  • 間違ったバージョンの: パイプラインが実行されますが、ソース/YAML の予期しないバージョンが使用されています。
  • 不足状態の更新: Azure Pipelines が状態の更新を報告していないため、GitHub PR がブロックされます。

接続の種類

トリガーのトラブルシューティングを行うには、パイプラインに使用している GitHub 接続の種類を知る方法を教えてください。

トリガーに関する問題のトラブルシューティングは、パイプラインで使用する GitHub 接続の種類によって大きく異なります。 接続の種類を決定するには、GitHub と Azure Pipelines の 2 つの方法があります。

  • GitHub から: GitHub アプリを使用するようにリポジトリが設定されている場合、PR とコミットの状態は Check Runs になります。 リポジトリに OAuth または PAT 接続を使用して Azure Pipelines が設定されている場合、状態は "古い" スタイルの状態になります。 状態が Check Runs か単純な状態かを判断する簡単な方法は、GitHub PR の [会話] タブを確認する方法です。

    • [詳細] リンクが [チェック] タブにリダイレクトされる場合は、Check Run であり、リポジトリはアプリを使用しています。
    • "詳細" リンクが Azure DevOps パイプラインにリダイレクトされる場合、状態は "古いスタイル" 状態になり、リポジトリはアプリを使用していません。

  • Azure Pipelines から: Azure Pipelines UI でパイプラインを調べることで、接続の種類を決定することもできます。 パイプラインのエディターを開きます。 トリガー を選択して、パイプラインのクラシック エディターを開きます。 次に、[YAML] タブ 選択し、[ソースの取得] 手順 します。 接続を使用して承認 バナーが表示されます。、パイプラインを GitHub と統合するために使用されたサービス接続を示します。 サービス接続の名前はハイパーリンクです。 これを選択して、サービス接続のプロパティに移動します。 サービス接続のプロパティは、使用されている接続の種類を示します。

    • Azure Pipelines アプリ が GitHub アプリ接続を示す
    • oauth が OAuth 接続を示す
    • personalaccesstoken が PAT 認証を示

OAuth ではなく GitHub アプリを使用するようにパイプラインを切り替えるにはどうすればよいですか?

OAuth または PAT 接続の代わりに GitHub アプリを使用することは、GitHub と Azure Pipelines の間の推奨される統合です。 GitHub アプリに切り替えるには、次の手順に従います。

  1. ここで 移動し、リポジトリの GitHub 組織にアプリをインストールします。
  2. インストール中に、Azure DevOps にリダイレクトされ、Azure DevOps の組織とプロジェクトが選択されます。 アプリを使用するクラシック ビルド パイプラインを含む組織とプロジェクトを選択します。 この選択により、GitHub アプリのインストールが Azure DevOps 組織に関連付けられます。 正しく選択しない場合は、このページ にアクセスして、GitHub 組織から GitHub アプリをアンインストールしてやり直すことができます。
  3. 次に表示されるページでは、新しいパイプラインの作成を続行する必要はありません。
  4. パイプラインのページ (たとえば、https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)) にアクセスし、パイプラインを選択し、[編集] をクリックして、パイプラインを編集します。
  5. これが YAML パイプラインの場合は、[トリガー] メニューを選択してクラシック エディターを開きます。
  6. パイプラインで [ソースの取得] ステップを選択します。
  7. "接続を使用して承認されました" というテキストの緑色のバーで、[変更] を選択し、アプリをインストールした GitHub 組織と同じ名前の GitHub アプリ接続を選択します。
  8. ツール バーの [保存してキュー] を選択し、[保存してキューに保存] を選択します。 キューに登録されたパイプライン実行へのリンクを選択して、成功したことを確認します。
  9. GitHub リポジトリに pull request を作成 (または閉じて再度開く) して、ビルドが "Checks" セクションで正常にキューに入っていることを確認します。

Azure Pipelines で選択できる GitHub リポジトリが表示されないのはなぜですか?

リポジトリの認証の種類と所有権に応じて、特定のアクセス許可が必要です。

  • GitHub アプリを使用している場合は、GitHub アプリ認証を参照してください。
  • OAuth を使用している場合は、OAuth 認証を参照してください。
  • PAT を使用している場合は、個人用アクセス トークン (PAT) 認証に関するページを参照してください。

パイプラインの作成時にリポジトリを選択すると、"リポジトリ {repo-name} は別の Azure DevOps 組織の Azure Pipelines GitHub アプリで使用されています" というエラーが表示されます。

これは、リポジトリが別の組織のパイプラインに既に関連付けられていることを意味します。 このリポジトリからの CI イベントと PR イベントは、他の組織に配信されるため機能しません。 パイプラインの作成に進む前に、他の組織へのマッピングを削除するために実行する必要がある手順を次に示します。

  1. GitHub リポジトリで pull request を開き、コメントを /azp whereします。 これにより、リポジトリがマップされている Azure DevOps 組織が報告されます。

  2. マッピングを変更するには、GitHub 組織からアプリをアンインストールし、再インストールします。 再インストールするときは、Azure DevOps にリダイレクトされたときに適切な組織を選択してください。

失敗したトリガー

CI/PR トリガーを使用して新しい YAML パイプラインを作成しましたが、パイプラインはトリガーされていません。

失敗したトリガーのトラブルシューティングを行うには、次の各手順に従います。

  • YAML CI または PR トリガー UIのパイプライン設定によってオーバーライドされますか? パイプラインの編集中に、[...] 選択し、[トリガーを します。

    パイプライン設定 UI を します。

    リポジトリで使用可能なトリガーの種類 (継続的インテグレーション または pull request 検証) の設定、ここから YAML トリガーをオーバーライドする を確認します。

    ここから YAML トリガーをオーバーライドします。

  • GitHub アプリ接続を使用して、パイプラインを GitHub に接続していますか? 接続の種類 を参照して、接続の種類を確認します。 GitHub アプリ接続を使用している場合は、次の手順に従います。

    • GitHub と Azure DevOps の間でマッピングが正しく設定されていますか? GitHub リポジトリで pull request を開き、コメントを /azp whereします。 これにより、リポジトリがマップされている Azure DevOps 組織が報告されます。

      • アプリを使用してこのリポジトリをビルドするように組織が設定されていない場合は、https://github.com/<org_name>/<repo_name>/settings/installations に移動し、アプリの構成を完了します。

      • 別の Azure DevOps 組織が報告された場合、他のユーザーが別の組織でこのリポジトリのパイプラインを既に確立しています。 現在、GitHub リポジトリを 1 つの DevOps 組織にのみマップできる制限があります。最初の Azure DevOps 組織のパイプラインのみが自動的にトリガーされます。 マッピングを変更するには、GitHub 組織からアプリをアンインストールし、再インストールします。 再インストールするときは、Azure DevOps にリダイレクトされたときに適切な組織を選択してください。

  • OAuth または PAT を使用してパイプラインを GitHub に接続していますか? 接続の種類 を参照して、接続の種類を確認します。 GitHub 接続を使用している場合は、次の手順に従います。

    1. OAuth 接続と PAT 接続は、更新を Azure Pipelines に通信するために Webhook に依存します。 GitHub で、リポジトリの設定に移動し、次に Webhook に移動します。 Webhook が存在することを確認します。 通常、3 つの Webhook (プッシュ、pull_request、issue_comment) が表示されます。 そうでない場合は、サービス接続を再作成し、新しいサービス接続を使用するようにパイプラインを更新する必要があります。

    2. GitHub で各 Webhook を選択し、ユーザーのコミットに対応するペイロードが存在し、Azure DevOps に正常に送信されたことを確認します。 イベントを Azure DevOps に通信できなかった場合は、ここでエラーが表示されることがあります。

  • Azure DevOps からのトラフィックは、GitHub によって調整される可能性があります。 Azure Pipelines は、GitHub から通知を受け取ると、GitHub に連絡し、リポジトリと YAML ファイルに関する詳細情報を取得しようとします。 多数の更新とプル要求を含むリポジトリがある場合、このような調整が原因でこの呼び出しが失敗する可能性があります。 この場合は、バッチ処理またはより厳密なパス/分岐フィルターを使用して、ビルドの頻度を減らすことができるかどうかを確認します。

  • パイプラインが一時停止されているか無効になっているか。 パイプラインのエディターを開き、[設定] 選択して確認します。 パイプラインが一時停止または無効になっている場合、トリガーは機能しません。

  • 正しいブランチの YAML ファイルを更新しましたか? ブランチに更新をプッシュすると、同じブランチ内の YAML ファイルによって CI 動作が制御されます。 ソース ブランチに更新をプッシュすると、ソース ブランチとターゲット ブランチのマージによって生じる YAML ファイルによって PR 動作が制御されます。 正しいブランチの YAML ファイルに必要な CI または PR 構成があることを確認します。

  • トリガーを正しく構成しましたか? YAML トリガーを定義する場合は、ブランチ、タグ、パスに対して include 句と exclude 句の両方を指定できます。 include 句がコミットの詳細と一致し、exclude 句がそれらを除外していないことを確認します。 トリガーの構文を確認し、正確であることを確認します。

  • トリガーまたはパスの定義に変数を使用しましたか? これはサポートされていません。

  • YAML ファイルにテンプレートを使用しましたか? その場合は、トリガーがメインの YAML ファイルで定義されていることを確認します。 テンプレート ファイル内で定義されたトリガーはサポートされていません。

  • 変更をプッシュしたブランチまたはパスを除外しましたか? 含まれているブランチに含まれるパスに変更をプッシュしてテストします。 トリガー内のパスでは大文字と小文字が区別されることに注意してください。 トリガーでパスを指定するときは、実際のフォルダーと同じケースを使用してください。

  • 新しいブランチをプッシュしましたか? その場合、新しいブランチが新しい実行を開始しない可能性があります。 「新しいブランチが作成されたときのトリガーの動作」セクションを参照してください。

CI または PR トリガーが正常に動作しています。 しかし、彼らは今作業を停止しました。

まず、前の質問のトラブルシューティング手順を実行してから、次の追加の手順に従います。

  • PR でマージ競合が発生していますか? パイプラインをトリガーしなかった PR の場合は、パイプラインを開き、マージの競合があるかどうかを確認します。 マージの競合を解決します。

  • プッシュ イベントまたは PR イベントの処理に遅延が発生していますか? 通常、問題が 1 つのパイプラインに固有であるか、プロジェクト内のすべてのパイプラインまたはリポジトリに共通しているかどうかを確認することで、遅延を確認できます。 いずれかのリポジトリへのプッシュまたは PR 更新でこの現象が発生した場合、更新イベントの処理に遅延が発生している可能性があります。 遅延が発生する理由を次に示します。

    • の状態ページでサービスの停止が発生しています。 状態ページに問題が表示される場合は、チームが既に作業を開始している必要があります。 この問題に関する更新プログラムについては、このページを頻繁に確認してください。
    • リポジトリに含まれる YAML パイプラインが多すぎます。 パフォーマンスを最大限に高めるには、1 つのリポジトリに最大 50 個のパイプラインを使用することをお勧めします。 許容可能なパフォーマンスを得る場合は、1 つのリポジトリに最大 100 個のパイプラインを使用することをお勧めします。 パイプラインが多いほど、そのリポジトリへのプッシュの処理が遅くなります。 リポジトリへのプッシュがある場合は常に、Azure Pipelines はそのリポジトリ内のすべての YAML パイプラインを読み込み、実行する必要があるかどうかを判断する必要があり、新しいパイプラインごとにパフォーマンスの低下が発生します。

ユーザーが YAML ファイルを更新するときに、トリガーのブランチの一覧をオーバーライドしないようにします。 これを行うにはどうすればよいですか?

コードを投稿するアクセス許可を持つユーザーは、YAML ファイルを更新し、追加のブランチを含める/除外することができます。 その結果、ユーザーは独自の機能またはユーザー ブランチを YAML ファイルに含め、その更新プログラムを機能またはユーザー ブランチにプッシュできます。 これにより、そのブランチに対するすべての更新に対してパイプラインがトリガーされる可能性があります。 この動作を回避する場合は、次のことができます。

  1. Azure Pipelines UI でパイプラインを編集します。
  2. トリガー メニューに移動します。
  3. ここから YAML 継続的インテグレーション トリガーをオーバーライド 選択します。
  4. トリガーに含める、または除外する分岐を指定します。

これらの手順を実行すると、YAML ファイルで指定された CI トリガーはすべて無視されます。

チェックアウトの失敗

チェックアウトの手順中に、ログ ファイルに次のエラーが表示されます。 どのように修正すればよいですか?

remote: Repository not found.
fatal: repository <repo> not found

これは、GitHub の停止が原因である可能性があります。 GitHub でリポジトリにアクセスして、アクセスできることを確認します。

バージョンが正しくありません

パイプラインで間違ったバージョンの YAML ファイルが使用されています。 それはどうしてですか。

  • CI トリガーの場合、プッシュしているブランチにある YAML ファイルが評価され、CI ビルドを実行する必要があるかどうかを確認します。
  • PR トリガーの場合、PR のソースブランチとターゲットブランチをマージした結果の YAML ファイルが評価され、PR ビルドを実行する必要があるかどうかを確認します。

不足している状態の更新

Azure Pipelines が状態を更新しなかったため、GitHub の PR がブロックされます。

これは、Azure DevOps が GitHub と通信できなくなる一時的なエラーである可能性があります。 GitHub アプリを使用する場合は、チェックイン GitHub を再試行してください。 または、PR を簡単に更新して、問題が解決できるかどうかを確認します。