Git または TFS Git リポジトリAzure Reposビルドする

Azure DevOps Services |Azure DevOps Server 2022 - Azure DevOps Server 2019 |TFS 2018

Note

Microsoft Team Foundation Server (TFS) 2018 以前のバージョンでは、ビルドとリリースの "パイプライン" は "定義"、"実行" は "ビルド"、"サービス接続" は "サービス エンドポイント"、"ステージ" は "環境"、"ジョブ" は "フェーズ" と呼ばれます。

Azure Pipelines では、すべての pull request を自動的に構築して検証し、Azure Repos Git リポジトリに対してコミットできます。

ビルドするリポジトリを選択する

YAML

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

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

YAML パイプラインは TFS では使用できません。

クラシック

パイプラインの作成時に、ビルドするリポジトリを選択するには、まずリポジトリが属するプロジェクトを選択します。 次に、リポジトリを選択します。

パイプラインの一部として追加のリポジトリを複製するには:

• リポジトリがパイプラインと同じプロジェクト内にある場合、またはアクセス トークン (後述) が別のプロジェクトのリポジトリにアクセスできる場合は、次のコマンドを使用します。

  git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" <clone URL>

  スクリプトで を使用 System.AccessToken するには、まずスクリプトで使用できるようにする必要があります。 これを行うには、エディターの [ タスク ] タブでジョブを選択し、右側のパネルで [追加のオプション] を選択し、[ スクリプトによる OAuth トークンへのアクセスを許可する] オプションをオンにします。

• アクセス トークン (後述) がリポジトリにアクセスできない場合:

  1. スコープを持つCode (read)個人用アクセス トークン (PAT) を取得し、プレフィックスを付けますPAT:
  2. 基本認証トークンを作成するには、この文字列を Base64 エンコードします。
  3. 次のコマンドを使用してパイプラインにスクリプトを追加して、そのリポジトリを複製します git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

ビルドをトリガーし、ビルド中にコードをフェッチするには、Azure Pipelines にリポジトリへのアクセス権を付与する必要があります。 通常、パイプラインは同じプロジェクト内のリポジトリにアクセスできます。 ただし、別のプロジェクトのリポジトリにアクセスする場合は、 ジョブ アクセス トークンに付与されたアクセス許可を更新する必要があります。

CI トリガー

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

YAML

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

ブランチ

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

trigger:
- master
- releases/*

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

Note

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

Note

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

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

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

上記の例では、変更が master または任意のリリース ブランチにプッシュされると、パイプラインがトリガーされます。 ただし、 で始まる 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 実行のバッチ処理

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

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

Note

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

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

Note

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

パス

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

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

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

ワイルド カードはパス フィルターでサポートされています。 たとえば、 と一致 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 実行を開始する必要があるかどうかを判断します。

YAML パイプラインは TFS では使用できません。

クラシック

他のユーザーがコードをチェックインするたびにビルドを実行する場合は、[トリガー] タブで [継続的インテグレーションを有効にする] を選択して、このトリガーを有効にします。

バッチ変更

多くのチーム メンバーが頻繁に変更をアップロードしていて、実行しているビルドの数を減らす場合は、このチェック ボックスをオンにします。 このオプションを選択すると、ビルドが実行されているときに、システムは実行が完了するまで待機し、まだビルドされていないすべての変更の別の実行をキューに入れます。

変更をバッチ処理して一緒にビルドできます。

Note

複数ステージの YAML パイプラインでバッチ処理を使用する場合は、次の 1 つを開始する前に、実行が終了状態に達する必要があります。 多くの場合、これは、複数ステージのパイプラインが承認と実行時間の長いデプロイ ステージを通過する可能性があるため、望ましくありません。 このような場合は、次のいずれかのソリューションに従うことをお勧めします。

• バッチ処理を使用しない
• パイプラインを 2 つの別個のパイプラインに分割します 。1 つは CI 用と 1 つの CD 用です
• ステージに適切な条件を設定してそれらをスキップし、実行をすばやく終了させる

分岐フィルター

ビルドをトリガーするブランチを指定できます。 ワイルドカード文字を使用する場合は、ブランチの指定 (例: ) を入力し、 features/modules/*Enter キーを押します。

パス フィルター

Git リポジトリが Azure Repos または TFS にある場合は、パス フィルターを指定して、ビルドをトリガーするファイルのセットを減らすこともできます。

ヒント:

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

例

たとえば、マスターブランチの変更によってビルドをトリガーし、機能ブランチのほとんど(すべてではない)でトリガーする必要があります。 また、ツール フォルダー内のファイルに対する変更によってビルドがトリガーされないようにする必要もあります。

個々のプッシュの CI のスキップ

また、プッシュが通常トリガーするパイプラインの実行をスキップするように Azure Pipelines に指示することもできます。 プッシュの一部であるコミットのメッセージに を含める ***NO_CI*** だけで、Azure Pipelines はこのプッシュの 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 トリガーを構成できます。 たとえば、フォルダーに更新をプッシュするときに 1 つのパイプラインをトリガーし、アプリケーション コードに docs 更新をプッシュするときにトリガーするパイプラインを 1 つ作成できます。 このような場合は、新しいブランチが作成されたときにパイプラインがどのようにトリガーされるかを理解する必要があります。

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

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

ワイルドカード

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

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

trigger:
  branches:
    include:
    - master
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

PR トリガー

pull request (PR) トリガーを使用すると、pull request を開くたびに、または変更をプッシュするたびにパイプラインが実行されます。 Azure Repos Git では、この機能はブランチ ポリシーを使用して実装されます。 PR 検証を有効にするには、目的のブランチのブランチ ポリシーに移動し、そのブランチの ビルド検証ポリシー を構成します。 詳細については、「 ブランチ ポリシーを構成する」を参照してください。

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

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

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

Note

Azure Repos Git リポジトリの検証ビルドを構成するには、そのプロジェクトのプロジェクト管理者である必要があります。

Note

下書きプル要求では、 ブランチ ポリシーを構成してもパイプラインはトリガーされません。

フォークからのコントリビューションを検証する

Azure Reposフォークからの pull request のビルドは、同じリポジトリまたはプロジェクト内で pull request をビルドするのと変わりません。 フォークは、プロジェクトが含まれているのと同じ組織内でのみ作成できます。

ジョブ承認スコープを制限する

Azure Pipelines には、パイプラインで実行されるジョブ承認スコープを構成するためのセキュリティ設定がいくつか用意されています。

• ジョブ承認スコープを現在のプロジェクトに制限する
• YAML パイプライン内のリポジトリへのアクセスを保護する

ジョブ承認スコープを現在のプロジェクトに制限する

Azure Pipelines には、次の 2 つの 制限ジョブ承認スコープが現在のプロジェクト設定に 用意されています。

• 非リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限する - この設定は、YAML パイプラインとクラシック ビルド パイプラインに適用されます。 この設定は、クラシック リリース パイプラインには適用されません。
• リリース パイプラインのジョブ承認スコープを現在のプロジェクトに制限する - この設定は 、クラシック リリース パイプライン にのみ適用されます。

パイプラインは、パイプラインの種類に関連する設定が有効になっていない限り、コレクション スコープのアクセス トークンで実行されます。 [ ジョブ承認スコープの制限 ] 設定を使用すると、現在のプロジェクトに対するすべてのパイプラインのアクセススコープを減らすことができます。 これは、組織内の別のプロジェクトのAzure Repos Git リポジトリにアクセスする場合に、パイプラインに影響を与える可能性があります。

Azure Repos Git リポジトリがパイプラインとは異なるプロジェクトにあり、パイプラインの種類の [ジョブ承認スコープの制限] 設定が有効になっている場合は、パイプラインのビルド サービス ID に対するアクセス許可を 2 番目のプロジェクトに付与する必要があります。 詳細については、「 ビルド サービス アカウントのアクセス許可を管理する」を参照してください。

Azure Pipelines には、パイプラインで実行されるジョブ承認スコープを構成するためのセキュリティ設定が用意されています。

• ジョブ承認スコープを現在のプロジェクトに制限する - この設定は、YAML パイプラインとクラシック ビルド パイプラインに適用されます。 この設定は 、クラシック リリース パイプラインには適用されません。

パイプラインは、 ジョブ承認スコープを現在のプロジェクトに制限 しない限り、コレクション スコープのアクセス トークンで実行されます。 この設定を使用すると、現在のプロジェクトに対するすべてのパイプラインのアクセス範囲を減らすことができます。 これは、組織内の別のプロジェクトのAzure Repos Git リポジトリにアクセスする場合に、パイプラインに影響を与える可能性があります。

Azure Repos Git リポジトリがパイプラインとは異なるプロジェクトにあり、[ジョブ承認スコープの制限] 設定が有効になっている場合は、パイプラインのビルド サービス ID に対するアクセス許可を 2 番目のプロジェクトに付与する必要があります。 詳細については、「 ジョブ承認スコープ」を参照してください。

ジョブ承認スコープの制限の詳細については、「ジョブ アクセス トークンについて」を参照してください。

ジョブ承認スコープを参照先の Azure DevOps リポジトリに制限する

パイプラインは、前の「 ジョブ承認スコープを現在 のプロジェクトに制限する」セクションで説明したように、承認されたプロジェクト内のすべての Azure DevOps リポジトリにアクセスできます。ただし、 参照先の Azure DevOps リポジトリへのジョブ承認スコープの制限 が有効になっている場合を除きます。 このオプションを有効にすると、すべてのパイプラインのアクセススコープを、そのリポジトリを使用するパイプライン ジョブ内のステップまたはusesステートメントによってcheckout明示的に参照される Azure DevOps リポジトリのみに減らすことができます。

この設定を構成するには、[パイプライン]、[組織の設定] または [プロジェクトの設定] で [設定] に移動します。 組織レベルで有効にした場合、設定は淡色表示され、プロジェクト設定レベルでは使用できません。

[参照先の Azure DevOps リポジトリにジョブ承認スコープを制限する] が有効になっている場合、YAML パイプラインは、リポジトリを使用するジョブのチェックアウト ステップとして、パイプラインで使用するAzure Repos Git リポジトリを明示的に参照する必要があります。 そのリポジトリが最初に明示的に参照されていない限り、Azure Repos Git リポジトリのスクリプト タスクと git コマンドを使用してコードをフェッチすることはできません。

[参照先の Azure DevOps リポジトリへのジョブ承認スコープを制限する] が有効になっている場合、パイプラインで使用する前に、Azure Repos Git リポジトリを明示的に参照する必要がない場合は、いくつかの例外があります。

• パイプラインに明示的なチェックアウト ステップがない場合は、ステップがあるかのようにcheckout: selfself、リポジトリがチェックアウトされます。
• スクリプトを使用してパブリック プロジェクトのリポジトリに対して読み取り専用操作を実行する場合、ステップで checkout パブリック プロジェクト リポジトリを参照する必要はありません。
• PAT など、リポジトリに独自の認証を提供するスクリプトを使用している場合は、そのリポジトリをステップで checkout 参照する必要はありません。

たとえば、 参照先の Azure DevOps リポジトリへのジョブ承認スコープの制限 が有効になっている場合、パイプラインが組織内のリポジトリにあり FabrikamProject/Fabrikam 、スクリプトを使用してリポジトリをチェックアウト FabrikamProject/FabrikamTools する場合は、ステップまたはステートメントで checkout このリポジトリを uses 参照する必要があります。

チェックアウト ステップを FabrikamTools 使用してパイプライン内のリポジトリを既にチェックアウトしている場合は、その後スクリプトを使用してそのリポジトリを操作できます。

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Note

多くのシナリオでは、マルチリポジトリチェックアウトを利用できるため、スクリプトを使用してパイプライン内の追加のリポジトリをチェックアウトする必要はありません。 詳細については、「 パイプライン内の複数のリポジトリをチェックアウトする」を参照してください。

YAML パイプラインのリポジトリへのアクセスを保護する

パイプラインは、「YAML パイプラインのリポジトリへのアクセスを保護する」が有効になっていない限り、「 ジョブ承認スコープを現在のプロジェクトに制限する 」セクションで説明したように、承認されたプロジェクト内のすべての Azure DevOps リポジトリにアクセス できます。 このオプションを有効にすると、すべてのパイプラインのアクセススコープを、そのリポジトリを使用するパイプライン ジョブのステップまたはusesステートメントによってcheckout明示的に参照される Azure DevOps リポジトリのみに減らすことができます。

この設定を構成するには、[ パイプライン]、[ 組織の設定] または [プロジェクト設定] の [ 設定 ] に移動 します。 組織レベルで有効にすると、設定は淡色表示され、プロジェクト設定レベルでは使用できません。

重要

YAML パイプラインのリポジトリへの保護アクセス は、2020 年 5 月以降に作成された新しい組織とプロジェクトに対して既定で有効になっています。 YAML パイプラインのリポジトリへのアクセスを保護する が有効になっている場合、YAML パイプラインは、リポジトリを使用するジョブのチェックアウト ステップとして、パイプラインで使用するAzure Repos Git リポジトリを明示的に参照する必要があります。 そのリポジトリが最初に明示的に参照されていない限り、Azure Repos Git リポジトリのスクリプト タスクと git コマンドを使用してコードをフェッチすることはできません。

YAML パイプラインのリポジトリへのアクセスを保護するが有効になっている場合、パイプラインで使用する前に、Azure Repos Git リポジトリを明示的に参照する必要がない場合は、いくつかの例外があります。

• パイプラインに明示的なチェックアウト ステップがない場合は、ステップがあるかのようにcheckout: selfself、リポジトリがチェックアウトされます。
• スクリプトを使用してパブリック プロジェクトのリポジトリに対して読み取り専用操作を実行する場合、ステップで checkout パブリック プロジェクト リポジトリを参照する必要はありません。
• PAT など、リポジトリに独自の認証を提供するスクリプトを使用している場合は、そのリポジトリをステップで checkout 参照する必要はありません。

たとえば、[ YAML パイプライン内のリポジトリへのアクセスを保護 する] が有効になっている場合、パイプラインが組織内のリポジトリにあり FabrikamProject/Fabrikam 、スクリプトを使用してリポジトリをチェックアウト FabrikamProject/FabrikamTools する場合は、ステップで、または ステートメントを checkout 使用してこのリポジトリを uses 参照する必要があります。

チェックアウト ステップを FabrikamTools 使用してパイプライン内のリポジトリを既にチェックアウトしている場合は、その後スクリプトを使用してそのリポジトリを操作できます。

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo
# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools
steps:
- script: # Do something with that repo like clone it

Note

多くのシナリオでは、マルチリポジトリチェックアウトを利用できるため、スクリプトを使用してパイプライン内の追加のリポジトリをチェックアウトする必要はありません。 詳細については、「 パイプライン内の複数のリポジトリをチェックアウトする」を参照してください。

チェックアウト

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

Note

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

Git の優先バージョン

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

チェックアウト パス

YAML

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

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

クラシック

この設定は、クラシック エディターでは構成できません。 ソース コードは、 と呼ばれる sディレクトリにチェックアウトされます。これは、 に対する $(Agent.BuildDirectory)相対ディレクトリです。 たとえば、 が C:\agent\_work\1の場合$(Agent.BuildDirectory)、ソース コードは にC:\agent\_work\1\mycustompathチェックアウトされます。

サブモジュール

YAML

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

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

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

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

[Checkout submodules]\(サブモジュールのチェックアウト\) オプションを使用できない場合は、代わりにカスタム スクリプト ステップを使用してサブモジュールをフェッチできます。 まず、個人用アクセス トークン (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 コマンドでシークレットを設定します。

Note

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

タグを同期する

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

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

YAML

この設定は fetchTags 、パイプラインの チェックアウト ステップで構成できます。

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

steps:
- checkout: self
  fetchTags: true

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

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

   

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

   

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

   

Note

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

クラシック

[ タグの同期 ] 設定は、パイプラインの [ソースの取得 ] タスクのプロパティから構成できます。

既定の動作

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

Note

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

シャロー フェッチ

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

重要

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

YAML

この設定は 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. [シャロー フェッチ] 設定を構成します。 シャロー フェッチをオフにしてシャロー フェッチを無効にするか、ボックスをオンにして Depth を入力してシャロー フェッチを有効にします。

   

Note

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

クラシック

パイプラインの [ソースの取得] タスクのプロパティから、シャロー フェッチ設定を構成できます。

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

Note

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

ソースを同期しない

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

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

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

YAML

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

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

クラシック

パイプライン の [ソースの 取得] タスクのプロパティから [ ソース を同期しない] 設定を選択します。

Note

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

クリーン ビルド

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

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

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

Note

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

YAML

この設定は 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

が ビルド パイプラインにtrue設定されている場合cleanは、 の変更を元に$(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 リポジトリが初期化されます。

クラシック

パイプラインの [ソースの取得] タスクのプロパティから [クリーン] 設定を選択し、次のいずれかのオプションを選択します。

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

  git clean -ffdx
  git reset --hard HEAD
  

• ソースと出力ディレクトリ: 上記の [ソース] オプションと同じ操作に加えて、 を削除して再作成します $(Build.BinariesDirectory)。 $(Build.ArtifactStagingDirectory)と $(Common.TestResultsDirectory) は、これらの設定に関係なく、すべてのビルドの前に常に削除および再作成されることに注意してください。

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

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

ラベル ソース

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

YAML

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

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

クラシック

パイプラインの [ソースの取得] タスクのプロパティから [ソースのタグ付け] 設定を構成できます。

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

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

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

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

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

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

よく寄せられる質問

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

• 失敗したトリガー: リポジトリに更新をプッシュするときにパイプラインがトリガーされません。
• チェックアウトの失敗: パイプラインがトリガーされていますが、チェックアウト 手順で失敗します。
• 間違ったバージョン: パイプラインは実行されますが、ソース/YAML の予期しないバージョンが使用されています。

失敗したトリガー

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

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

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

  

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

  

• リポジトリの YAML ファイルまたはブランチ ポリシーで PR トリガーを構成していますか? Azure Repos Git リポジトリの場合、YAML ファイルで PR トリガーを構成することはできません。 ブランチ ポリシーを使用する必要があります。

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

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

• トリガーを正しく構成しましたか? YAML トリガーを定義するときに、ブランチ、タグ、パスのインクルード句と 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 トリガーはすべて無視されます。

YAML パイプラインに複数のリポジトリがあります。 各リポジトリ操作方法トリガーを設定しますか?

「複数のリポジトリを使用する」のトリガーを参照してください。

チェックアウトの失敗

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

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

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

• リポジトリはまだ存在しますか? 最初に、[ Repos ] ページで開くことを確認します。

• スクリプトを使用してリポジトリにアクセスしていますか? その場合は、 参照先の Azure DevOps リポジトリにジョブ承認スコープを制限する 設定を確認します。 [参照先の Azure DevOps リポジトリにジョブ承認スコープを制限する] が有効になっている場合、パイプラインで最初に明示的に参照されていない限り、スクリプトを使用して Git リポジトリAzure Reposチェックアウトすることはできません。

• パイプラインの ジョブ承認スコープ は何ですか?

  • スコープが コレクションの場合:

    • これは断続的なエラーである可能性があります。 パイプラインを再実行します。
    • 誰かが Project Collection Build Service アカウントへのアクセスを削除した可能性があります。
      • リポジトリが存在するプロジェクトの [プロジェクト 設定] に移動します。 [ Repos > Repositories specific repository]\(リポジトリ リポジトリ固有の > リポジトリ\) を選択し、[Security]\( セキュリティ\) を選択します。
      • ユーザーの一覧に Project Collection Build Service (your-collection-name) が存在するかどうかを確認します。
      • そのアカウントに [タグの作成] と [ 読み取り ] アクセス権があるかどうかを確認します。

  • スコープが プロジェクトの場合:

    • リポジトリはパイプラインと同じプロジェクトにありますか?
      • Yes:
        • これは断続的なエラーである可能性があります。 パイプラインを再実行します。
        • 誰かが Project Build Service アカウントへのアクセスを削除した可能性があります。
          • リポジトリが存在するプロジェクトの [プロジェクト の設定] に移動します。 [ Repos Repositories > specific repository]\(リポジトリ リポジトリ > 固有のリポジトリ\) を選択し、[Security]\(セキュリティ\) を 選択します。
          • ユーザーの一覧に your-project-name Build Service (your-collection-name) が存在するかどうかを確認します。
          • そのアカウントに [タグの作成] と [ 読み取り ] アクセスがあるかどうかを確認します。
      • No:
        • パイプラインはパブリック プロジェクトに含まれますか?
          • はい: パブリック プロジェクトの外部のリソースにアクセスすることはできません。 プロジェクトを非公開にします。
          • いいえ: 同じプロジェクト コレクション内の別のリポジトリにアクセスするためのアクセス許可を構成する必要があります。

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

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

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

関連記事

• スケジュールされたトリガー
• パイプライン完了トリガー