GitHub リポジトリを作成する

Azure Pipelines

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

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組織またはユーザーアカウントの Azure DevOps組織
  • GitHubリポジトリの Azure DevOpsプロジェクト

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

Azure DevOps で同一の構造を設定するには、次のようにします。

  1. GitHub 組織またはユーザーアカウントの後に、という名前の Azure DevOps 組織を作成します。 この URL は、のようになり https://dev.azure.com/your-organization ます。
  2. Azure DevOps 組織で、リポジトリの後にという名前のプロジェクトを作成します。 これらの Url は、のようになり https://dev.azure.com/your-organization/your-repository ます。
  3. Azure DevOps Project で、と GitHub いう名前のパイプラインを作成します (など) your-organization.your-repository 。 次に、その対象となるリポジトリを明確にします。

このパターンに従うと、GitHub リポジトリと Azure DevOps プロジェクトの URL パスが一致するようになります。 たとえば、次のように入力します。

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

ユーザー

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

GitHub 組織の役割

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

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

GitHub 組織のロールと Azure DevOps 組織内の同等のロールは次のようになります。

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

ユーザーアカウントの役割を GitHub する

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

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

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

GitHub ユーザーアカウントの役割 組織と同等の Azure DevOps
所有者 メンバー Project Collection Administrators

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

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

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

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

GitHub リポジトリのアクセス許可 同等のプロジェクトを Azure DevOps
[Admin] メンバー Project Administrators
Write メンバー Contributors
読み取り メンバー Readers

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

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

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

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

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

新しいパイプラインを作成するには、最初に GitHub リポジトリを選択してから、そのリポジトリ内の yaml ファイルを選択します。 YAML ファイルが存在するリポジトリは、repository と呼ばれ self ます。 既定では、これはパイプラインがビルドするリポジトリです。

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

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

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

認証の種類 を使用して実行 Pipelines 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 チェックと連携して、ビルド、テスト、およびコードカバレッジの結果を GitHub に表示します。

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

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

GitHub 組織内のすべてのリポジトリに GitHub アプリをインストールする場合、大量の電子メールを送信したり、お客様に代わってパイプラインを自動的に設定したりする必要は Azure Pipelines ありません。 リポジトリ管理者は、すべてのリポジトリにアプリをインストールする代わりに、個々のリポジトリに対して一度に1つずつインストールすることもできます。 これには、管理者に対してより多くの作業が必要ですが、利点や欠点はありません。

GitHub に必要なアクセス許可

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

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

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

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

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

アプリのアクセス許可を GitHub する

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

アクセス許可 処理 Azure Pipelines
コードへの書き込みアクセス GitHub リポジトリの選択されたブランチに対して yaml ファイルをコミットすることによってパイプラインの作成が簡素化される Azure Pipelines のは、意図的にアクションを実行した場合だけです。
メタデータへの読み取りアクセス Azure Pipelines は、ビルドの概要で、ビルドに関連付けられているリポジトリ、分岐、および懸案事項を表示するための GitHub メタデータを取得します。
チェックの読み取りと書き込みのアクセス権 Azure Pipelines は、GitHub に表示される独自のビルド、テスト、およびコードカバレッジの結果を読み取り、書き込みます。
プル要求への読み取りおよび書き込みアクセス 意図的に操作した場合にのみ、Azure Pipelines は、GitHub リポジトリの選択したブランチにコミットされた yaml ファイルのプル要求を作成することによって、パイプラインの作成を簡略化します。 プル要求に関連付けられているビルドの概要に表示するプル要求のメタデータが Azure Pipelines によって取得されます。

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 に必要なアクセス許可

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

  • リポジトリが個人用 GitHub アカウントにある場合は、少なくとも1回は、個人の GitHub アカウント資格情報を使用して OAuth で GitHub するように認証します。 これを行うには、[Pipelines サービス接続] の [ > 新しいサービス接続 GitHub 承認] の下にある Azure DevOps プロジェクト設定を使用 >>> します。 ここでは、[アクセス許可] の下にリポジトリへのアクセスを許可 Azure Pipelines ます。

  • リポジトリが他のユーザーの個人用 GitHub アカウントにある場合は、少なくとも1回は、個人の GitHub アカウント資格情報を使用して OAuth で GitHub するために、もう一方のユーザーを認証する必要があります。 これを行うには、[Pipelines サービス接続] の [ > 新しいサービス接続 GitHub 承認] の下にある Azure DevOps プロジェクト設定を使用 >>> します。 その他のユーザーは、ここで[アクセス許可] の下にリポジトリへのアクセスを許可 Azure Pipelines 付与する必要があります。 "コラボレーター" の下のリポジトリの設定でコラボレーターとして追加する必要があります。 電子メールで送信されたリンクを使用して、コラボレーターになるよう招待を受け入れます。

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

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

OAuth アクセスの取り消し

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

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

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

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

GitHub に必要なアクセス許可

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

  • 自分の個人用アカウントにレポGitHub場合、PAT は個人用アクセス トークン(、および ) の下に必要なアクセス スコープ admin:repo_hookread:user 持っている必要があります user:email

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

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

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

PAT アクセスの取り消し

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

CI トリガー

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

YAML パイプラインは、すべてのブランチで CI トリガーを使用して既定で構成されます。

ブランチ

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

trigger:
- master
- releases/*

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

注意

変数は実行時 (トリガーが起動した後に) 評価されるので、トリガーで変数を使用することはできません。

注意

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

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

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

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

句を指定せずに 句を指定する場合は、 句で excludeinclude を指定するの * と同 include じです。

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

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

トリガーを指定しない場合、既定値は次のように書いています。

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

重要

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

CI 実行のバッチ処理

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

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

この例を明確にするために、マスターへのプッシュによって上記のパイプラインが実行 A されたとします。 そのパイプラインの実行中に、追加のプッシュ BC リポジトリへの実行が行われます。 これらの更新プログラムは、新しい独立した実行をすぐに開始する必要があります。 ただし、最初の実行が完了すると、その時点まですべてのプッシュがまとめてバッチ処理され、新しい実行が開始されます。

注意

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

パス

含めるファイル パスまたは除外するファイル パスを指定できます。

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

パスを指定する場合は、トリガーするブランチを明示的に指定する必要があります。 パス フィルターのみを使用してパイプラインをトリガーできない。また、ブランチ フィルターが必要です。また、パス フィルターに一致する変更されたファイルは、ブランチ フィルターに一致するブランチからのファイルである必要があります。

ヒント:

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

タグ

前のセクションで説明した一覧でタグを指定する以外に、含めるタグまたは除外するタグ branches を直接指定できます。

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

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

重要

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

CI のオプトアウト

CI トリガーの無効化

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

# A pipeline with no CI trigger
trigger: none

重要

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

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

個々のコミットに対する CI のスキップ

また、コミットがAzure Pipelinesトリガーするパイプラインの実行をスキップする必要がある場合も、このコマンドを指定できます。 コミット メッセージまたは HEAD コミットの説明にを含めるだけで [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'))

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

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

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

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

ワイルドカード

ブランチまたはタグを指定する場合は、正確な名前またはワイルドカードを使用できます。 ワイルドカード パターンを使用すると * 、0 個以上の文字を一致させて ? 、1 文字に一致することができます。

  • YAML パイプラインで を使用してパターンを開始する場合は、 のようなパターンを引用符で * 囲む必要があります "*-releases"
  • 分岐、タグ、およびパスの場合は、ワイルドカードがパターン内の任意の場所に表示される場合があります。
trigger:
  branches:
    include:
    - master
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR トリガー

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

ブランチ

pull requests を検証するときに、ターゲット ブランチを指定できます。 たとえば、 と を対象とする pull request を検証するには masterreleases/* 、次のトリガーを使用 pr できます。

pr:
- master
- releases/*

この構成では、新しい更新プログラムが最初に作成され、pull requestに対して行われたすべての更新後に、新しい実行がpull request。

ブランチの完全名 (例: ) またはワイルドカード (例: master ) を指定できます releases/*

注意

変数は実行時 (トリガーが起動した後に) 評価されるので、トリガーで変数を使用することはできません。

注意

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

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

YAML ファイルにトリガーが表示されない場合、pull requestトリガーを作成した場合と同様に、すべてのブランチに対して自動的に検証 pr が有効 pr になります。 この構成では、任意のpull requestが作成され、コミットがアクティブなアプリケーションのソース ブランチに入pull request。

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

重要

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

特定のブランチを除外する必要があるより複雑なトリガーの場合は、次の例に示すように完全な構文を使用する必要があります。

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

パス

含めるファイル パスまたは除外するファイル パスを指定できます。 たとえば、次のように入力します。

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

ヒント:

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

複数の PR 更新プログラム

PR に対する追加の更新で、同じ PR の進行中の検証の実行を取り消すかどうかを指定できます。 既定値は、true です。

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

ドラフト PR 検証

既定では、pull requestプル要求とレビューの準備ができている pull request に対してトリガーが起動します。 ドラフト pull requests 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 起動しない場合は prのトラブルシューティング手順に従ってください。

注意

ドラフト pull request は パイプラインをトリガーしない。

保護されたブランチ

ブランチを対象とする各コミットまたは pull request を使用して検証ビルドを実行し、検証ビルドが成功するまで pull request がマージされるのを防ぐ場合があります。

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

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

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

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

    GitHubの状態チェック

重要

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

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

外部ソースからの投稿

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

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

アクセスの制限

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

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

フォークからの投稿

重要

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

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

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

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

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

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

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

  • パイプラインからシークレットをリークします。 このリスクを軽減するには、リポジトリがパブリックまたは信頼されていないユーザーがビルドを自動的にトリガーする pull request を送信できる場合は、[Make secrets to builds of forks]/(フォークのビルドでシークレットを使用可能にする)チェック ボックスをオンにすることはできません。 既定では、このオプションは無効になっています。

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

    • Microsoft ホ ステッド エージェント プールを使用して 、フォークからの pull request を作成します。 Microsoft ホステッド エージェント マシンはビルドの完了直後に削除されます。そのため、侵害された場合に影響が続く可能性はありません。

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

コメント トリガー

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

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

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

  1. パイプラインpull requestトリガーを有効にし、ターゲット ブランチを除外しなかったことを確認します。
  2. Web ポータルでAzure Pipelinesパイプラインを編集し、[その他のアクション]、[トリガー]を選択します。 次に 、[Pull request validation]/(Pull request の検証)で、 [Require a team member's comment before buildinga pull request.
    • [ すべての pull requests で] を 選択して、チーム メンバーのコメントを要求してからpull request。 このワークフローでは、チーム メンバーがプロジェクトをレビューしpull request安全と見なされると、コメントを含pull requestをトリガーします。
    • PR がチーム メンバー以外の メンバーによって行われた場合にのみチーム メンバーのコメントを要求するには、チーム メンバー以外のメンバーからの pull request に対してのみ選択します。 このワークフローでは、チーム メンバーは、ビルドをトリガーするためにセカンダリ チーム メンバーのレビューを必要とします。

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

次のコマンドを発行して、コメントAzure Pipelinesを追加できます。

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

注意

簡単に言って、 の代わりに を使用して /azp コメントを付けできます /AzurePipelines

重要

これらのコマンドに対する応答は、パイプラインpull requestアプリ を使用している場合にのみ、Azure Pipelines GitHub説明に表示されます

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

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

チェックアウト

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

注意

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

Git の推奨バージョン

このWindowsには、Git の独自のコピーが付属しています。 含まれているコピーを使用するのではなく、独自の Git を指定する場合は、 を に設定 System.PreferGitFromPath します true 。 この設定は、非クライアント エージェントでは常Windowsされます。

チェックアウト パス

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

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

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

設定は、 path パイプラインの [ 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

サブモジュール

サブモジュール からファイルをダウンロードする場合は、パイプラインの [チェックアウト] ステップで 設定 submodulesを構成できますsubmodules

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番目のプロジェクトのリポジトリにアクセスできる必要があります。 前のセクションで説明したように、ジョブアクセストークンを制限した場合、これを行うことはできません。 ジョブアクセストークンが2番目のプロジェクト内のリポジトリにアクセスできるようにするには、(a) 2 番目のプロジェクトのプロジェクトビルドサービスアカウントへのアクセスを明示的に付与するか、(b) 組織全体のプロジェクトスコープのトークンではなく、コレクションスコープのアクセストークンを使用します。 これらのオプションとそのセキュリティへの影響の詳細については、「 アクセスリポジトリ、アーティファクト、およびその他のリソース」を参照してください。

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

Checkout サブモジュールオプションを使用する代わりに

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

Checkout サブモジュールオプションを使用できない場合は、代わりにカスタムスクリプトステップを使用してサブモジュールをフェッチできます。 まず、個人用アクセストークン (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 credential manager を使用できないのはなぜですか。A: サブモジュールの資格情報をプライベートビルドエージェントにインストールされた Git 資格情報マネージャーに格納することは、通常、サブモジュールが更新されるたびに資格情報の再入力を求めるメッセージが表示されるため、有効ではありません。 これは、ユーザーの操作が不可能な場合に、自動ビルド中には望ましくありません。

簡易フェッチ

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

fetchDepthパイプラインの [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

このような場合は、このオプションを使用して、ネットワークリソースと記憶域リソースを節約できます。 時間を節約することもできます。 常に時間が節約されるとは限りません。状況によっては、指定した深度に対してダウンロードするコミットの計算に時間がかかることがあります。

注意

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

ソースを同期しない

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

  • 独自のカスタムオプションを使用して、Git の初期化、構成、およびフェッチを行います。

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

を設定することにより、パイプラインのチェックアウトステップで [ソースを同期しない] 設定を構成でき ます。

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

注意

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

ビルドのクリーン

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

一般に、自己ホスト型エージェントのパフォーマンスを向上させるには、リポジトリをクリーンにしないでください。 この場合、最適なパフォーマンスを得るには、ビルドに使用しているタスクまたはツールの クリーン オプションを無効にして、インクリメンタルビルドも実行していることを確認してください。

リポジトリをクリーニングする必要がある場合 (たとえば、以前のビルドの残りのファイルに起因する問題を回避するため)、オプションは次のようになります。

注意

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

cleanパイプラインの [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

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

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.ArtifactStagingDirectory)$(Common.TestResultsDirectory) これらの設定に関係なく、すべてのビルドの前に必ず削除され、再作成されることに注意してください。

  • resources: 削除と再作成を行い ます。 その結果、ビルドごとに新しいローカル Git リポジトリが初期化されます。

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

ソースのラベル付け

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

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

Git オプションの [YAML] を構成します。

クラシックエディターで、[ Yaml] を選択し、[ ソースの取得 ] タスクを選択して、必要なプロパティを構成します。

クラシックエディターで、[YAML Get sources] を選択し  ます。

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

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

最初の4つの変数はあらかじめ定義されています。 My.Variable [ 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

ステータスの更新

GitHub にポストバックされた状態を Azure Pipelines し、GitHub チェックを実行するステータスには、次の2種類があります。 GitHub チェック機能は GitHub アプリでのみ使用できます。

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

  • Pr の場合は、[PR 会話] タブに表示されます。
  • 個々のコミットについては、リポジトリの [コミット] タブのコミット時間の後にステータスマークをポイントすると表示されます。

PAT または OAuth GitHub 接続

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

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

GitHub チェック

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

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

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

GitHub の再実行の確認

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

よく寄せられる質問

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

  • 接続の種類:GitHub にパイプラインを接続するために使用している接続の種類が不明です。
  • 失敗したトリガー: リポジトリに更新をプッシュしたときに、自分のパイプラインがトリガーされていません。
  • チェックアウトの失敗: パイプラインがトリガーされていますが、チェックアウトステップで失敗しました。
  • バージョンが間違っています: パイプラインが実行されましたが、予期しないバージョンの source/YAML が使用されています。
  • 不足しているステータスの更新:Azure Pipelines がステータスの更新を報告しなかったため、GitHub pr がブロックされました。

接続の種類

トリガーのトラブルシューティングを行うには、パイプラインに使用している GitHub 接続の種類を確認するにはどうすればよいですか。

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

  • GitHub から: リポジトリが GitHub アプリを使用するように設定されている場合、pr とコミットの状態はチェックの実行になります。 リポジトリが OAuth または PAT 接続を使用して Azure Pipelines セットアップされている場合、状態は "old" スタイルの状態になります。 状態がチェックの実行か単純な状態かを簡単に判断するには、GitHub PR の [メッセージ交換] タブを確認します。

    • [詳細] リンクが [チェック] タブにリダイレクトされる場合は、チェックが実行され、リポジトリはアプリを使用しています。
    • [詳細] リンクを 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. パイプラインを編集するには、Pipelines ページ (たとえば、パイプラインを選択し、[編集] をクリックします。 https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build)
  5. これが YAML パイプラインの場合は、[ トリガー ] メニューを選択してクラシックエディターを開きます。
  6. パイプラインの "ソースの取得" ステップを選択します。
  7. 緑色のバーに "接続を使用して認証されました" というテキストが表示されている場合は、[変更] をクリックし、アプリをインストールした GitHub 組織と同じ名前の GitHub アプリ接続を選択します。
  8. ツールバーの [保存してキューに保存] を選択し、[保存してキューに保存] をクリックします。 キューに登録されたパイプライン実行のリンクをクリックして、成功したことを確認します。
  9. GitHub リポジトリでプル要求を作成 (または閉じて再度開き) し、ビルドが "チェック" セクションで正常にキューに登録されていることを確認します。

Azure Pipelines で GitHub リポジトリが表示されないのはなぜですか。

リポジトリの認証の種類と所有権によっては、特定のアクセス許可が必要になります。

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

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

  1. GitHub リポジトリでプル要求を開き、コメントを作成し /azp where ます。 これにより、リポジトリがマップされている Azure DevOps 組織が返されます。

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

失敗したトリガー

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

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

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

    パイプライン設定の UI。

    リポジトリで使用できるトリガーの種類 (継続的インテグレーションまたはプル要求の検証) については、[ここから yaml トリガーを上書きする] 設定を確認してください。

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

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

    • GitHub と Azure DevOps の間にマッピングが適切に設定されているか。 GitHub リポジトリでプル要求を開き、コメントを作成し /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 接続は、webhook を使用して Azure Pipelines に更新プログラムを伝達します。 GitHub で、リポジトリの設定、[webhook] の順に移動します。 Webhook が存在することを確認します。 通常は、プッシュ、pull_request、issue_comment という3つの webhook が表示されます。 そうでない場合は、サービス接続を再作成し、新しいサービス接続を使用するようにパイプラインを更新する必要があります。

    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 ファイルを更新するときに、トリガーのブランチの一覧を上書きしないようにします。 どうすればよいですか。

コードを投稿するためのアクセス許可を持つユーザーは、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 ビルドを実行する必要があるかどうかが確認されます。

不足しているステータスの更新

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

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