パイプラインの複数のリポジトリをチェックアウトする

[アーティクル]
06/16/2023

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2020

パイプラインは多くの場合、コードのビルドに必要なソース、ツール、スクリプト、その他の項目を含む複数のリポジトリに依存します。パイプラインで複数の checkout ステップを使うと、YAML パイプラインの格納に使うリポジトリに加えて、他のリポジトリもフェッチしてチェックアウトできます。

複数のリポジトリを指定する

リポジトリは、リポジトリリソースとして、または checkout ステップでインラインで、指定できます。

次のリポジトリの種類がサポートされています。

Azure Repos Git (git)

Azure DevOps Server (同じ組織内のリポジトリに制限されます)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

重要

Azure DevOps Server での複数リポジトリのチェックアウトでサポートされているのは、パイプラインと同じ組織内の Azure Repos Git (git) リポジトリのみです。

注意

Azure Pipelines には、Azure Repos Git リポジトリに対するジョブスコープの制限の設定が用意されています。別のプロジェクトでホストされている Azure Repos Git リポジトリをチェックアウトするには、アクセスを許可するようにジョブスコープの制限を構成する必要があります。詳しくは、「ジョブの承認スコープを制限する」をご覧ください。

次の checkout ステップの組み合わせがサポートされています。

checkout ステップなし

既定の動作は、checkout: self が最初のステップであった場合と同じであり、現在のリポジトリがチェックアウトされます。

1 つの checkout: none ステップ

リポジトリは同期またはチェックアウトされていません。

1 つの checkout: self ステップ

現在のリポジトリがチェックアウトされています。

checkout または self ではない 1 つの none ステップ

self ではなく、指定されたリポジトリがチェックアウトされます。

複数の checkout ステップ

path ステップで異なる checkout が指定されていない限り、指定された各リポジトリが、リポジトリの後で指定されている名前のフォルダーにチェックアウトされます。リポジトリの 1 つとして self をチェックアウトするには、checkout: self ステップの 1 つとして checkout を使います。

注意

パイプラインを含んでいない Azure Repos Git リポジトリでチェックアウトすると、初めてパイプラインが実行される前にそのリソースへのアクセスの承認を求められる場合があります。詳しくは、「FAQ」セクションの「別のリポジトリを初めてチェックアウトしようとすると、リソースの承認を求められるのはなぜですか?」をご覧ください。

リポジトリリソースの定義

リポジトリの種類でサービス接続またはその他の拡張リソースフィールドが必要な場合は、リポジトリリソースを使う必要があります。次のリポジトリの種類では、サービス接続が必要です。

リポジトリの種類	サービス接続
Bitbucket Cloud	Bitbucket Cloud
GitHub	GitHub
GitHub Enterprise Server	GitHub Enterprise Server
パイプラインとは異なる組織の Azure Repos Git リポジトリ	Azure Repos/Team Foundation Server

別のリポジトリ内のテンプレート用に既にリポジトリリソースが定義されている場合など、リポジトリの種類でサービス接続が必要ない場合でも、リポジトリリソースを使用できます。

次の例では、3 つのリポジトリがリポジトリリソースとして宣言されています。別の組織の Azure Repos Git リポジトリ、GitHub、および Bitbucket Cloud のリポジトリリソースには、それらのリポジトリリソースのとして指定されたサービス接続endpointが必要です。この例には 4 つの checkout ステップがあり、パイプライン YAML を含む現在の self リポジトリと共に、リポジトリリソースとして宣言された 3 つのリポジトリをチェックアウトします。

resources:
  repositories:
  - repository: MyGitHubRepo # The name used to reference this repository in the checkout step
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
  - repository: MyBitbucketRepo
    type: bitbucket
    endpoint: MyBitbucketServiceConnection
    name: MyBitbucketOrgOrUser/MyBitbucketRepo
  - repository: MyAzureReposGitRepository # In a different organization
    endpoint: MyAzureReposGitServiceConnection
    type: git
    name: OtherProject/MyAzureReposGitRepo

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- checkout: MyGitHubRepo
- checkout: MyBitbucketRepo
- checkout: MyAzureReposGitRepository

- script: dir $(Build.SourcesDirectory)

self リポジトリの名前が CurrentRepo である場合、script コマンドでは次の出力が生成されます: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo。この例では、checkout ステップで name が指定されていないため、リポジトリの (リポジトリリソースの path プロパティで指定されている) 名前がフォルダーに使われます。リポジトリフォルダーの名前と場所について詳しくは、次の「チェックアウトパス」セクションをご覧ください。

インライン構文のチェックアウト

リポジトリにサービス接続が必要ない場合は、checkout ステップを使ってそれをインラインで宣言できます。

注意

インライン構文を使用できるのは、同じ組織内の Azure Repos Git リポジトリのみです。別の組織内の Azure Repos Git リポジトリと、サポートされている他のリポジトリの種類では、サービス接続が必要であり、リポジトリリソースとして宣言する必要があります。

steps:
- checkout: self
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization

Note

前の例では、パイプラインに関連付けられたリポジトリのソースをチェックアウトするためにselfチェックアウトリポジトリが指定されています。

デフォルトのAzure Repose Gitリポジトリ（プロジェクトと同じ名前）を使用している場合は、- checkout: git://MyProject/MyRepoという形式を使用します。

チェックアウトパス

path ステップで checkout を指定しないと、ソースコードは既定のディレクトリに配置されます。このディレクトリは、チェックアウトするリポジトリが 1 つか複数かによって異なります。

1 つのリポジトリ: ジョブの checkout ステップが 1 つの場合、または checkout: self と同等のチェックアウトステップがない場合は、ソースコードは s のサブフォルダーである (Agent.BuildDirectory) というディレクトリにチェックアウトされます。 (Agent.BuildDirectory) が C:\agent\_work\1 である場合、コードは C:\agent\_work\1\s にチェックアウトされます。
複数のリポジトリ: ジョブに複数の checkout ステップがある場合は、ソースコードは、s の (Agent.BuildDirectory) のサブフォルダーとして、リポジトリの後で指定されている名前のディレクトリにチェックアウトされます。 (Agent.BuildDirectory) が C:\agent\_work\1 で、リポジトリの名前が tools と code である場合、コードは C:\agent\_work\1\s\tools と C:\agent\_work\1\s\code にチェックアウトされます。

注意

path ステップで checkout が指定されていない場合は、repository ステップでリポジトリを参照するために使われれる checkout の値ではなく、リポジトリの名前がフォルダーに使われます。

path ステップに checkout が指定されている場合は、(Agent.BuildDirectory) を基準にしてそのパスが使われます。

注意

既定のパスを使っている場合、2 番目のリポジトリ checkout ステップを追加すると、最初のリポジトリに対するコードの既定のパスが変更されます。たとえば、tools が唯一のリポジトリの場合は、C:\agent\_work\1\s という名前のリポジトリのコードは tools にチェックアウトされますが、2 つ目のリポジトリが追加されると、tools は C:\agent\_work\1\s\tools にチェックアウトされます。ソースコードが元の場所に存在することに依存するステップがある場合は、それらのステップを更新する必要があります。

特定の参照をチェックアウトする

特定の参照を指定しない場合、既定のブランチがチェックアウトされます。

インライン構文を使っている場合は、@<ref> を追加することで参照を指定します。次に例を示します。

- checkout: git://MyProject/MyRepo@features/tools # checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/heads/features/tools # also checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/tags/MyTag # checks out the commit referenced by MyTag.

リポジトリリソースを使っているときは、ref プロパティを使って参照を指定します。次の例では、指定したリポジトリの features/tools/ ブランチをチェックアウトします。

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: features/tools

steps:
- checkout: MyGitHubRepo

次の例では、タグを使って、MyTag によって参照されているコミットをチェックします。

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: refs/tags/MyTag

steps:
- checkout: MyGitHubRepo

トリガー

更新が self リポジトリまたはリソースとして宣言されているいずれかのリポジトリにプッシュされるときに、パイプラインをトリガーできます。これは、たとえば、次のシナリオで役に立ちます。

異なるリポジトリにあるツールまたはライブラリを使っています。ツールまたはライブラリが更新されるたびに、アプリケーションのテストを実行する必要があります。
アプリケーションコードとは別のリポジトリに、YAML ファイルを保持しています。更新がアプリケーションのリポジトリにプッシュされるたびに、パイプラインをトリガーする必要があります。

重要

リポジトリリソーストリガーは、同じ組織内のAzure Reposit Gitリポジトリに対してだけ機能し、selfリポジトリタイプがAzure Reposit Gitの場合にのみ機能します。 GitHub または Bitbucket のリポジトリリソースでは機能しません。

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

リポジトリリソースで trigger セクションを指定しない場合、パイプラインはそのリポジトリへの変更によってトリガーされません。 trigger セクションを指定した場合、トリガーの動作は、self リポジトリに対する CI トリガーの動作と似ています。

複数のリポジトリリソースに対して trigger セクションを指定した場合は、いずれかのリソースへの変更で、新しい実行が開始されます。

パイプラインがトリガーされると、Azure Pipelines は、使う必要がある YAML ファイルのバージョンと、チェックアウトする必要がある各リポジトリのバージョンを決定する必要があります。self リポジトリへの変更によってパイプラインがトリガーされた場合は、パイプラインをトリガーしたコミットを使って、YAML ファイルのバージョンが決定されます。他のリポジトリリソースへの変更によってパイプラインがトリガーされた場合は、 リポジトリの既定のブランチselfにある最新バージョンの YAML が使われます。

いずれかのリポジトリへの更新によってパイプラインがトリガーされると、トリガー元のリポジトリに基づいて次の変数が設定されます。

Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage

トリガー元リポジトリの場合、パイプラインをトリガーしたコミットによって、チェックアウトされるコードのバージョンが決まります。他のリポジトリの場合、そのリポジトリリソースの YAML で定義されている ref によって、チェックアウトされる既定のバージョンが決まります。

次のような例を考えます。self リポジトリには YAML ファイルが含まれ、リポジトリ A と B には追加のソースコードが含まれています。

trigger:
- main
- feature

resources:
  repositories:
  - repository: A
    type: git
    name: MyProject/A
    ref: main
    trigger:
    - main

  - repository: B
    type: git
    name: MyProject/B
    ref: release
    trigger:
    - main
    - release
steps:
- checkout: self
- checkout: A
- checkout: B

次の表は、上記のYAMLファイルを使用するパイプラインによって各リポジトリでチェックアウトされるバージョンを示しています。

変更されたもの	パイプラインがトリガーされるか	YAML のバージョン	`self` のバージョン	`A` のバージョン	`B` のバージョン
`main` の `self`	はい	パイプラインをトリガーした `main` からのコミット	パイプラインをトリガーした `main` からのコミット	`main` からの最新	`release` からの最新
`feature` の `self`	はい	パイプラインをトリガーした `feature` からのコミット	パイプラインをトリガーした `feature` からのコミット	`main` からの最新	`release` からの最新
`main` の `A`	はい	`main` からの最新	`main` からの最新	パイプラインをトリガーした `main` からのコミット	`release` からの最新
`main` の `B`	はい	`main` からの最新	`main` からの最新	`main` からの最新	パイプラインをトリガーした `main` からのコミット
`release` の `B`	はい	`main` からの最新	`main` からの最新	`main` からの最新	パイプラインをトリガーした `release` からのコミット

また、いずれかのリポジトリで pull request を作成または更新したときに、パイプラインをトリガーすることもできます。これを行うには、上の例のように YAML ファイルでリポジトリリソースを宣言し、リポジトリでブランチポリシーを構成します (Azure Repos のみ)。

リポジトリの詳細

複数のリポジトリをチェックアウトするとき、self リポジトリに関する一部の詳細を、変数として使用できます。複数リポジトリのトリガーを使うときは、それらの変数の一部に、代わりにトリガー元リポジトリに関する情報が含まれます。ジョブによって使われるすべてのリポジトリに関する詳細は、というテンプレートコンテキストオブジェクトresources.repositoriesとして使用できます。

たとえば、self ではないリポジトリの参照を取得するには、次のようなパイプラインを記述できます。

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: |
    echo "Tools version: $TOOLS_REF"

よく寄せられる質問

別のプロジェクトからリポジトリをチェックアウトできないのはなぜですか? 以前は動作していました。
別のリポジトリを初めてチェックアウトしようとすると、リソースの承認を求められるのはなぜですか?

別のプロジェクトからリポジトリをチェックアウトできないのはなぜですか? 以前は動作していました。

Azure Pipelines には、現在のプロジェクトにジョブ承認スコープを制限する設定があります。この設定を有効にすると、パイプラインが含まれるプロジェクトの外部にあるリソースには、パイプラインからアクセスできなくなります。この設定は、組織またはプロジェクトレベルで設定できます。この設定を有効にすると、明示的にアクセスを付与しない限り、別のプロジェクトのリポジトリからチェックアウトはできません。詳しくは、「ジョブ承認スコープ」をご覧ください。

別のリポジトリを初めてチェックアウトしようとすると、リソースの承認を求められるのはなぜですか?

パイプラインを含んでいない Azure Repos Git リポジトリでチェックアウトすると、初めてパイプラインが実行される前にそのリソースへのアクセスの承認を求められる場合があります。これらのプロンプトは、パイプライン実行の概要ページに表示されます。

このパイプラインは、リソースにアクセスするためにアクセス許可が必要です

リソースを承認します

[表示] または [リソースの承認] を選び、プロンプトに従ってリソースを承認します。

レビュー待ち

アクセスを許可します

詳しくは、「YAML パイプライン承認のトラブルシューティング」をご覧ください。

次の方法で共有

パイプラインの複数のリポジトリをチェックアウトする

複数のリポジトリを指定する

リポジトリリソースの定義

インライン構文のチェックアウト

チェックアウトパス

特定の参照をチェックアウトする

トリガー

リポジトリの詳細

よく寄せられる質問

別のプロジェクトからリポジトリをチェックアウトできないのはなぜですか? 以前は動作していました。

別のリポジトリを初めてチェックアウトしようとすると、リソースの承認を求められるのはなぜですか?

フィードバック

その他のリソース

次の方法で共有

パイプラインの複数のリポジトリをチェックアウトする

複数のリポジトリを指定する

リポジトリ リソースの定義

インライン構文のチェックアウト

チェックアウト パス

特定の参照をチェックアウトする

トリガー

リポジトリの詳細

よく寄せられる質問

別のプロジェクトからリポジトリをチェックアウトできないのはなぜですか? 以前は動作していました。

別のリポジトリを初めてチェックアウトしようとすると、リソースの承認を求められるのはなぜですか?

フィードバック

その他のリソース

リポジトリリソースの定義

チェックアウトパス