GitHub リポジトリを作成する

Azure Pipelines

Azure Pipelinesを自動的にビルドして検証し、pull requestリポジトリにコミットGitHubできます。 この記事では、アプリケーションとサービス間の統合を構成するGitHubについて説明Azure Pipelines。

Azure Pipelines と GitHub の統合を初めて使用する場合は、「最初のパイプラインを作成する」の手順に従って、GitHub リポジトリを操作する最初のパイプラインを取得してから、この記事に戻って、GitHub と Azure Pipelines の統合の構成とカスタマイズの詳細を確認してください。

組織とユーザー

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

組織

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

GitHub組織構造

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

Azure DevOps組織構造

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

  • 組織Azure DevOps ユーザー アカウントGitHub 組織
  • Azure DevOps リポジトリ の GitHub プロジェクト

GitHubにマップされた Azure DevOps

同一の構造体を設定するには、次Azure DevOps。

  1. 組織またはAzure DevOpsアカウントにちなんで名前が付GitHub組織を作成します。 のような 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 ID はGitHubに注意してください。 このため、GitHub ID と電子メール アドレスを使用して、ビルドエラーまたは PR 検証エラーをユーザーに自動的に通知する Azure Pipelines を構成する方法はありません。 ユーザーをレプリケートするには、新しいユーザーを Azure Pipelinesに作成GitHubがあります。 新しいユーザーを作成したら、ユーザーのアクセス許可を Azure DevOps に反映するようにアクセス許可を構成GitHub。 また、ユーザー ID を使用してAzure DevOps通知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 アカウント ロールの追加

1 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/collaboration 換えてください) your-organization にあります your-repository

Azure DevOpsのアクセス許可は( と に置き https://dev.azure.com/your-organization/your-project/_settings/security 換えてください) に your-organization 見つかりました your-project

リポジトリとプロジェクトのGitHubの同等のAzure DevOpsは次のとおりです。

GitHubのアクセス許可 Azure DevOps同等のプロジェクト
[Admin] メンバー Project Administrators
Write メンバー Contributors
Read メンバー 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 ファイルが存在するリポジトリはリポジトリと呼 self ばれる。 既定では、これはパイプラインがビルドするリポジトリです。

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

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

パイプラインの作成時に、Azure PipelinesリポジトリへのGitHubを許可するための認証の種類は 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 > サービス > 接続] の下にある Azure DevOps のプロジェクト設定を使用して、[新しいサービス接続 > GitHub > 承認します。 ここでは、[アクセス許可] の下にリポジトリへのアクセスを許可 Azure Pipelines ます。

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

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

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

OAuth アクセスの取り消し

oauth を使用するように Azure Pipelines を承認した後、後でそれを失効させ、それ以上使用できないようにするには、GitHub 設定でoauth アプリにアクセスしてください。 また、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 に必要なアクセス許可

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

  • リポジトリが個人の GitHub アカウントにある場合、PAT は、、、、およびの個人用アクセストークンに必要なアクセススコープを持っている必要があり repo admin:repo_hook read:user user:email ます。

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

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

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

PAT アクセスの取り消し

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

CI トリガー

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

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

ブランチ

次の簡単な構文を使用して、どの分岐が CI トリガーを取得するかを制御できます。

trigger:
- master
- releases/*

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

注意

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

注意

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

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

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

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

句を指定せずに句を指定する場合は、句 exclude include でを指定することと同じです * 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 実行のバッチ処理

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

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

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

注意

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

パス

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

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

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

ヒント:

  • ワイルドカードは、パスフィルターではサポートされていません。
  • パスは常に、リポジトリのルートを基準として指定されます。
  • パスフィルターを設定しない場合、既定では、リポジトリのルートフォルダーが暗黙的に含まれます。
  • パスを除外する場合は、さらに深いフォルダーに修飾しない限り、パスを含めることはできません。 たとえば、 /ツール を除外した場合は、 のように指定することができます。
  • パスフィルターの順序は重要ではありません。
  • 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 指示することもできます。 [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 トリガー

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

ブランチ

プル要求を検証するときに、ターゲット分岐を指定できます。 たとえば、およびを対象とするプル要求を検証するに master releases/* は、次のトリガーを使用でき pr ます。

pr:
- master
- releases/*

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

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

注意

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

注意

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

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

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

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

ヒント:

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

複数の PR の更新

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

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

PR 検証のドラフト

既定では、プル要求のトリガーはドラフトのプル要求と、レビューの準備ができているプル要求に対して起動されます。 ドラフトプル要求のプル要求トリガーを無効にするには、プロパティをに設定し 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 検証をオプトアウトする

を指定することで、プル要求の検証を完全に無効にすることができ pr: none ます。

# no PR triggers
pr: none

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

注意

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

注意

ドラフトプル要求 は、パイプラインをトリガーしません。

保護されたブランチ

分岐をターゲットとするコミットまたはプル要求ごとに検証ビルドを実行できます。また、検証ビルドが成功するまでプル要求がマージされないようにすることもできます。

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

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

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

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

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

重要

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

外部ソースからの投稿

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

外部ソースからの投稿を受け入れるときにパブリックプロジェクトで Azure Pipelines を使用する場合は、次の点に注意してください。

アクセスの制限

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

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

フォークからの投稿

重要

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

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

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

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

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

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

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

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

  • エージェントを実行しているコンピューターで、他のパイプラインからのコードまたはシークレットを盗むことができます。 これを軽減するには:

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

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

コメントトリガー

リポジトリコラボレーターは、パイプラインを手動で実行するプル要求にコメントできます。 これを行う理由として、いくつかの一般的な理由があります。

  • 変更内容を確認できるようになるまで、不明なユーザーからプル要求を自動的に作成することはできません。 チームメンバーの1人が最初にコードを確認してから、パイプラインを実行します。 これは、フォークされたリポジトリからコードを作成するときに、セキュリティ対策としてよく使用されます。
  • オプションのテストスイートまたは追加の検証ビルドを実行することができます。

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

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

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

次のコマンドを発行して、コメント内の Azure Pipelines することができます。

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

注意

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

重要

これらのコマンドへの応答は、パイプラインでAzure Pipelines GitHub アプリが使用されている場合にのみ、プル要求の説明に表示されます。

プル要求のコメントトリガーのトラブルシューティング

必要なリポジトリのアクセス許可を持っているにもかかわらず、コメントによってパイプラインがトリガーされない場合は、そのメンバーシップがリポジトリの組織で 公開 されていることを確認するか、リポジトリのコラボレーターとして直接追加してください。 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

複数の手順を使用し、複数のリポジトリをチェックアウトし、 を使用してフォルダーを明示的に指定していない場合、各リポジトリは、リポジトリの名前が付いた のサブフォルダー checkout path s に配置されます。 たとえば、 と という名前の 2 つのリポジトリをチェックアウトすると、ソース コードは と tools code にチェックアウト 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 )。

設定は、 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 を構成できます

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 サブモジュールがチェックアウトされます。

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

  • 認証:

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

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

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

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

      • これはチェックアウトされません。 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 資格情報マネージャーを使用できない理由 A: プライベート ビルド エージェントにインストールされている Git 資格情報マネージャーにサブモジュール資格情報を格納すると、通常は有効ではありません。サブモジュールが更新されるたびに資格情報マネージャーから資格情報の再入力を求める場合があります。 これは、ユーザーの操作ができない場合の自動ビルドでは望ましくありません。

シャロー フェッチ

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

設定は、 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 の init、config、fetch。

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

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

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

注意

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

クリーン ビルド

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

一般に、セルフホステッド エージェントのパフォーマンスを向上させるには、レポポをクリーンアップしない必要があります。 この場合、最高のパフォーマンスを得る場合は、ビルドに使用しているタスクまたはツールの [クリーン ] オプションを無効にして、増分的にビルドも行う必要があります。

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

注意

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

設定は、 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

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

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

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

  • all: を削除して再作成します $(Agent.BuildDirectory) 。 その結果、ビルドごとに新しいローカル Git リポジトリが初期化されます。

ソースのラベル付け

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

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

Git オプションの [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

ステータスの更新

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 接続の種類によって異なります。 接続の種類を確認するには、2 つの方法があります。接続の種類は、GitHubと Azure Pipelines。

  • [GitHubから: GitHub アプリを使用するリポジトリが設定されている場合、そのリポジトリの状態は [実行の確認] になります。 OAuth または PAT Azure Pipelines設定されている場合、状態は "古い" スタイルの状態になります。 状態が [実行の確認] または [単純な状態] かどうかを確認する簡単な方法は、PR の [会話] タブGitHubです。

    • [詳細] リンクが [チェック] タブにリダイレクトされる場合は、Check Run であり、レポポがアプリを使用しています。
    • "詳細" リンクが Azure DevOps パイプラインにリダイレクトされた場合、状態は "古いスタイル" 状態であり、レポポはアプリを使用していない。
  • [Azure Pipelines: UI でパイプラインを検査することで、接続の種類Azure Pipelinesできます。 パイプラインのエディターを開きます。 [ トリガー] を 選択して、パイプラインのクラシック エディターを開きます。 次に 、[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 リポジトリ内に pull request を作成 (または閉じて再度開く) して、ビルドが "Checks" セクションで正常にキューに登録されたことを確認します。

自分が選択するGitHubのリポジトリが表示されないAzure Pipelines。

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

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

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

  1. リポジトリでpull requestを開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? リポジトリでpull requestを開GitHub、コメント を作成します /azp where 。 これにより、リポジトリがAzure DevOps組織のレポートが返されます。

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

      • 別の組織Azure DevOps報告された場合、他のユーザーが別の組織でこのレポポのパイプラインを既に確立しています。 現時点では、1 つの組織に対して 1 つのGitHubをマップできるDevOpsがあります。最初の組織のパイプラインAzure DevOps自動的にトリガーできます。 マッピングを変更するには、組織からアプリGitHubし、再インストールします。 再インストールする際は、新しい組織にリダイレクトするときに、必ず正しい組織Azure DevOps。

  • OAuth または PAT を使用してパイプラインを接続GitHub? 接続 の種類については、「 接続の種類」を参照してください。 接続を使用している場合はGitHub手順に従います。

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

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

  • トラフィックは、Azure DevOpsによって調整される可能性GitHub。 ユーザー Azure Pipelinesから通知を受け取GitHub、GitHub に接続し、レポポと YAML ファイルに関する詳細をフェッチします。 多数の更新と pull request を含むレポポがある場合、このような調整のためにこの呼び出しが失敗する可能性があります。 この場合は、バッチ処理またはより厳密なパス/分岐フィルターを使用して、ビルドの頻度を減らすことが可能な場合を確認します。

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

  • 正しいブランチの 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. UI でパイプラインをAzure Pipelinesします。
  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更新しなかったAzure Pipelinesの PR がブロックされます。

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