Udostępnij za pośrednictwem

Zapoznaj się z wieloma repozytoriami w potoku

  • Artykuł

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

Potoki często bazują na wielu repozytoriach, które zawierają źródło, narzędzia, skrypty lub inne elementy potrzebne do kompilacji kodu. Korzystając z wielu checkout kroków w potoku, możesz pobrać i wyewidencjonować inne repozytoria oprócz tego, którego używasz do przechowywania potoku YAML.

Określanie wielu repozytoriów

Repozytoria mogą być określane jako zasób repozytorium lub wbudowane w checkout kroku.

Obsługiwane są następujące typy repozytoriów.

Azure Repos Git (git)

  • Azure DevOps Server (ograniczony do repozytoriów w tej samej organizacji)
  • Azure DevOps Services

GitHub (github)

  • Azure DevOps Services

GitHubEnterprise (githubenterprise)

  • Azure DevOps Services

Bitbucket Cloud (bitbucket)

  • Azure DevOps Services

Ważne

Tylko repozytoria Git usługi Azure Repos (git) w tej samej organizacji co potok są obsługiwane w przypadku wyewidencjonowania wielu repozytoriów w usłudze Azure DevOps Server.

Uwaga

Usługa Azure Pipelines udostępnia ustawienia zakresu zadań limitu dla repozytoriów Git usługi Azure Repos. Aby sprawdzić repozytoria Git usługi Azure Repos hostowane w innym projekcie, należy skonfigurować zakres zadań limitu, aby zezwolić na dostęp. Aby uzyskać więcej informacji, zobacz Ograniczanie zakresu autoryzacji zadań.

Obsługiwane są następujące kombinacje kroków checkout .

Brak checkout kroków

Domyślne zachowanie wygląda tak, jakby checkout: self było pierwszym krokiem, a bieżące repozytorium jest wyewidencjonowane.

Jeden checkout: none krok

Żadne repozytoria nie są synchronizowane ani wyewidencjonowane.

Jeden checkout: self krok

Bieżące repozytorium jest wyewidencjonowane.

Pojedynczy checkout krok, który nie self jest lub none

Wyznaczone repozytorium jest wyewidencjonowane zamiast self.

Wiele checkout kroków

Każde wyznaczone repozytorium jest wyewidencjonowane do folderu o nazwie po repozytorium, chyba że w checkout kroku określono inne path repozytorium. Aby zapoznać się self z jednym z repozytoriów, użyj polecenia checkout: self jako jednego z checkout kroków.

Uwaga

Podczas wyewidencjonowania repozytoriów Git usługi Azure Repos innych niż zawierające potok może zostać wyświetlony monit o autoryzację dostępu do tego zasobu przed pierwszym przebiegiem potoku. Aby uzyskać więcej informacji, zobacz Dlaczego otrzymuję monit o autoryzowanie zasobów przy pierwszej próbie wyewidencjonowania innego repozytorium? w sekcji Często zadawane pytania .

Definicja zasobu repozytorium

Jeśli typ repozytorium wymaga połączenia z usługą lub innego pola zasobów rozszerzonych, musisz użyć zasobu repozytorium. Następujące typy repozytoriów wymagają połączenia z usługą.

Typ repozytorium Połączenie z usługą
Bitbucket Cloud Bitbucket Cloud
GitHub GitHub
Serwer GitHub Enterprise GitHub Enterprise Server
Repozytoria Git usługi Azure Repos w innej organizacji niż potok Azure Repos/Team Foundation Server

Możesz użyć zasobu repozytorium, nawet jeśli typ repozytorium nie wymaga połączenia z usługą, na przykład jeśli masz zasób repozytorium zdefiniowany już dla szablonów w innym repozytorium.

W poniższym przykładzie trzy repozytoria są deklarowane jako zasoby repozytorium. Repozytorium Git usługi Azure Repos w innej organizacji, usłudze GitHub i zasobach repozytorium Usługi Bitbucket w chmurze wymagają połączeń usług, które są określone jako endpoint dla tych zasobów repozytorium. Ten przykład zawiera cztery checkout kroki, które sprawdzają trzy repozytoria zadeklarowane jako zasoby repozytorium wraz z bieżącym self repozytorium zawierającym potok YAML.

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 Jeśli repozytorium ma nazwę CurrentRepo, script polecenie generuje następujące dane wyjściowe: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. W tym przykładzie nazwy repozytoriów (określone przez name właściwość w zasobie repozytorium) są używane dla folderów, ponieważ nie określono jej path w kroku wyewidencjonowania. Aby uzyskać więcej informacji na temat nazw i lokalizacji folderów repozytorium, zobacz następującą sekcję Ścieżka wyewidencjonowania.

Wyewidencjonuj składnię śródliniową

Jeśli repozytorium nie wymaga połączenia z usługą, możesz zadeklarować je w tekście przy użyciu kroku checkout .

Uwaga

Tylko repozytoria Git usługi Azure Repos w tej samej organizacji mogą używać składni wbudowanej. Repozytoria Git usługi Azure Repos w innej organizacji i inne obsługiwane typy repozytoriów wymagają połączenia z usługą i muszą zostać zadeklarowane jako zasób repozytorium.

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

Uwaga

W poprzednim przykładzie self repozytorium wyewidencjonowania jest określone w celu wyewidencjonowania źródła repozytorium skojarzonego z potokiem.

Jeśli używasz domyślnego repozytorium Git usługi Azure Repos (które ma taką samą nazwę jak projekt), użyj formatu - checkout: git://MyProject/MyRepo.

Ścieżka wyewidencjonowania

Jeśli element nie path zostanie określony w checkout kroku, kod źródłowy zostanie umieszczony w katalogu domyślnym. Ten katalog różni się w zależności od tego, czy wyewidencjonujesz pojedyncze repozytorium, czy wiele repozytoriów.

  • Pojedyncze repozytorium: jeśli masz jeden checkout krok w zadaniu lub nie masz kroku wyewidencjonowania, który jest odpowiednikiem checkout: self, kod źródłowy jest wyewidencjonowany w katalogu o nazwie s znajdującym się jako podfolder .(Agent.BuildDirectory) Jeśli (Agent.BuildDirectory) wartość to C:\agent\_work\1, kod jest wyewidencjonowany na .C:\agent\_work\1\s

  • Wiele repozytoriów: jeśli masz wiele checkout kroków w zadaniu, kod źródłowy zostanie wyewidencjonowany w katalogach nazwanych po repozytoriach jako podfolder s w (Agent.BuildDirectory)pliku . Jeśli (Agent.BuildDirectory) nazwa to i C:\agent\_work\1 repozytoria mają nazwę tools i code, kod jest wyewidencjonowany do C:\agent\_work\1\s\tools i C:\agent\_work\1\s\code.

    Uwaga

    Jeśli w kroku nie path określono checkout wartości , nazwa repozytorium jest używana dla folderu, a nie repository wartość używana do odwołowania się do repozytorium w checkout kroku.

path Jeśli parametr jest określony dla checkout kroku, ta ścieżka jest używana względem (Agent.BuildDirectory)elementu .

Uwaga

Jeśli używasz ścieżek domyślnych, dodanie drugiego kroku repozytorium checkout zmienia domyślną ścieżkę kodu dla pierwszego repozytorium. Na przykład kod repozytorium o nazwie tools zostanie wyewidencjonowany w C:\agent\_work\1\s przypadku, gdy tools jest jedynym repozytorium, ale jeśli zostanie dodane drugie repozytorium, tools zostanie wyewidencjonowany do C:\agent\_work\1\s\tools. Jeśli masz jakiekolwiek kroki, które zależą od kodu źródłowego w oryginalnej lokalizacji, należy zaktualizować te kroki.

Wyewidencjonowanie konkretnego odwołania

Gałąź domyślna jest wyewidencjonowana, o ile nie wyznaczysz określonego odwołania.

Jeśli używasz składni wbudowanej, wyznacz odwołanie, dołączając @<ref>element . Na przykład:

- 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.

W przypadku korzystania z zasobu repozytorium określ odwołanie przy użyciu ref właściwości . Poniższy przykład sprawdza features/tools/ gałąź wyznaczonego repozytorium.

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

steps:
- checkout: MyGitHubRepo

W poniższym przykładzie użyto tagów do wyewidencjonowania zatwierdzenia, do których odwołuje się MyTagelement .

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

steps:
- checkout: MyGitHubRepo

Wyzwalacze

Potok można wyzwolić, gdy aktualizacja zostanie wypchnięta do self repozytorium lub do dowolnego repozytorium zadeklarowanego jako zasoby. Jest to przydatne na przykład w następujących scenariuszach:

  • Używasz narzędzia lub biblioteki z innego repozytorium. Chcesz uruchamiać testy dla aplikacji za każdym razem, gdy narzędzie lub biblioteka zostanie zaktualizowana.
  • Plik YAML należy przechowywać w osobnym repozytorium od kodu aplikacji. Chcesz wyzwolić potok za każdym razem, gdy aktualizacja zostanie wypchnięta do repozytorium aplikacji.

Ważne

Wyzwalacze zasobu repozytorium działają tylko dla repozytoriów Git usługi Azure Repos w tej samej organizacji i gdy self typ repozytorium to Azure Repos Git. Nie działają one w przypadku zasobów repozytorium GitHub ani Bitbucket.

batch nie jest obsługiwany w wyzwalaczach zasobów repozytorium.

Jeśli nie określisz trigger sekcji w zasobie repozytorium, potok nie zostanie wyzwolony przez zmiany w tym repozytorium. Jeśli określisz sekcję trigger , zachowanie wyzwalania jest podobne do sposobu działania wyzwalaczy ciągłej integracji dla repozytorium samodzielnego.

Jeśli określisz sekcję trigger dla wielu zasobów repozytorium, zmiana dowolnej z nich spowoduje uruchomienie nowego uruchomienia.

Po wyzwoleniu potoku usługa Azure Pipelines musi określić wersję pliku YAML, która powinna być używana, oraz wersję dla każdego repozytorium, które powinno zostać wyewidencjonowane. Jeśli zmiana self w repozytorium wyzwoli potok, zatwierdzenie, które wyzwoliło potok, zostanie użyte do określenia wersji pliku YAML. Jeśli w potoku zostanie wyzwolona zmiana innego zasobu repozytorium, zostanie użyta najnowsza wersja kodu YAML z domyślnej self gałęzi repozytorium.

Gdy aktualizacja do jednego z repozytoriów wyzwoli potok, następujące zmienne są ustawiane na podstawie wyzwalania repozytorium:

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

W przypadku repozytorium wyzwalającego zatwierdzenie, które wyzwoliło potok, określa wersję wyewidencjonowanego kodu. W przypadku innych repozytoriów ref zdefiniowany w pliku YAML dla tego zasobu repozytorium określa wersję domyślną, która jest wyewidencjonowana.

Rozważmy poniższy przykład, w którym self repozytorium zawiera plik YAML i repozytoria A oraz B zawiera dodatkowy kod źródłowy.

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

W poniższej tabeli przedstawiono wersje wyewidencjonowane dla każdego repozytorium przez potok przy użyciu powyższego pliku YAML.

Zmiana wprowadzona na Potok został wyzwolony Wersja kodu YAML Wersja self Wersja A Wersja B
main w systemie self Tak zatwierdzenie z main tego wyzwalało potok zatwierdzenie z main tego wyzwalało potok najnowsza wersja main najnowsza wersja release
feature w systemie self Tak zatwierdzenie z feature tego wyzwalało potok zatwierdzenie z feature tego wyzwalało potok najnowsza wersja main najnowsza wersja release
main w systemie A Tak najnowsza wersja main najnowsza wersja main zatwierdzenie z main tego wyzwalało potok najnowsza wersja release
main w systemie B Tak najnowsza wersja main najnowsza wersja main najnowsza wersja main zatwierdzenie z main tego wyzwalało potok
release w systemie B Tak najnowsza wersja main najnowsza wersja main najnowsza wersja main zatwierdzenie z release tego wyzwalało potok

Potok można również wyzwolić podczas tworzenia lub aktualizowania żądania ściągnięcia w dowolnym repozytorium. W tym celu zadeklaruj zasoby repozytorium w plikach YAML, jak w powyższych przykładach, i skonfiguruj zasady gałęzi w repozytorium (tylko usługa Azure Repos).

Szczegóły repozytorium

Podczas wyewidencjonowywanie self wielu repozytoriów niektóre szczegóły dotyczące repozytorium są dostępne jako zmienne. W przypadku korzystania z wyzwalaczy z wieloma repozytoriami niektóre z tych zmiennych zawierają informacje o repozytorium wyzwalającym. Szczegółowe informacje o wszystkich repozytoriach używanych przez zadanie są dostępne jako obiekt kontekstu szablonu o nazwie resources.repositories.

Aby na przykład uzyskać odwołanie do repozytorium innegoself niż repozytorium, możesz napisać potok w następujący sposób:

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"

Często zadawane pytania

Dlaczego nie mogę wyewidencjonować repozytorium z innego projektu? Wcześniej to działało.

Usługa Azure Pipelines udostępnia Ograniczenie zakresu autoryzacji zadań dla bieżącego ustawienia projektu, które po włączeniu nie zezwala potokowi na dostęp do zasobów poza projektem zawierającym potok. To ustawienie można określić na poziomie organizacji lub projektu. Jeśli to ustawienie jest włączone, nie będzie można wyewidencjonować repozytorium w innym projekcie, chyba że jawnie udzielisz dostępu. Aby uzyskać więcej informacji, zobacz Zakres autoryzacji zadań.

Dlaczego otrzymuję monit o autoryzowanie zasobów przy pierwszej próbie wyewidencjonowania innego repozytorium?

Podczas wyewidencjonowania repozytoriów Git usługi Azure Repos innych niż zawierające potok może zostać wyświetlony monit o autoryzację dostępu do tego zasobu przed pierwszym przebiegiem potoku. Te monity są wyświetlane na stronie podsumowania przebiegu potoku.

Ten potok musi mieć uprawnienia dostępu do zasobu

Autoryzowanie zasobu

Wybierz pozycję Wyświetl lub Autoryzuj zasoby i postępuj zgodnie z monitami, aby autoryzować zasoby.

Oczekiwanie na przegląd

Zezwalaj na dostęp

Aby uzyskać więcej informacji, zobacz Rozwiązywanie problemów z autoryzacją dla potoku YAML.