パイプラインの複数のリポジトリをチェックアウトする
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://MyRepo/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.IDBuild.Repository.NameBuild.Repository.ProviderBuild.Repository.UriBuild.SourceBranchBuild.SourceBranchNameBuild.SourceVersionBuild.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 パイプライン承認のトラブルシューティング」をご覧ください。
フィードバック
以下は間もなく提供いたします。2024 年を通じて、コンテンツのフィードバック メカニズムとして GitHub の issue を段階的に廃止し、新しいフィードバック システムに置き換えます。 詳細については、「https://aka.ms/ContentUserFeedback」を参照してください。
フィードバックの送信と表示