Tworzenie repozytoriów Git usługi Azure Repos lub TFS Git

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Usługa Azure Pipelines może automatycznie kompilować i weryfikować każde żądanie ściągnięcia oraz zatwierdzać repozytorium Git usługi Azure Repos.

Wybieranie repozytorium do skompilowania

YAML

Utwórz nowy potok, wybierając najpierw repozytorium, a następnie plik YAML w tym repozytorium. Repozytorium, w którym znajduje się plik YAML, jest nazywane self repozytorium. Domyślnie jest to repozytorium kompilowane przez potok.

Później możesz skonfigurować potok, aby wyewidencjonować inne repozytorium lub wiele repozytoriów. Aby dowiedzieć się, jak to zrobić, zobacz wyewidencjonowania z wieloma repozytoriami.

Klasyczny

Podczas tworzenia potoku, aby wybrać repozytorium do skompilowania, najpierw wybierz projekt, do którego należy repozytorium. Następnie wybierz repozytorium.

Aby sklonować dodatkowe repozytoria w ramach potoku:

• Jeśli repozytorium znajduje się w tym samym projekcie co potok lub jeśli token dostępu (opisany poniżej) ma dostęp do repozytorium w innym projekcie, użyj następującego polecenia:

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

  Aby można było użyć System.AccessToken skryptu, należy najpierw udostępnić go skryptowi. W tym celu wybierz zadanie na karcie Zadania w edytorze, wybierz pozycję Dodatkowe opcje w prawym panelu i zaznacz opcję Zezwalaj skryptom na dostęp do tokenu OAuth.

• Jeśli token dostępu (opisany poniżej) nie ma dostępu do repozytorium:

  1. Uzyskiwanie osobistego tokenu dostępu (PAT) z zakresem Code (read) i jego prefiksem za pomocą polecenia PAT:
  2. Kodowanie tego ciągu w formacie Base64 w celu utworzenia podstawowego tokenu uwierzytelniania.
  3. Dodaj skrypt w potoku za pomocą następującego polecenia, aby sklonować to repozytorium git clone -c http.extraheader="AUTHORIZATION: basic <BASIC_AUTH_TOKEN>" <clone URL>

Usługa Azure Pipelines musi mieć dostęp do repozytoriów w celu wyzwolenia kompilacji i pobrania kodu podczas kompilacji. Zwykle potok ma dostęp do repozytoriów w tym samym projekcie. Jeśli jednak chcesz uzyskać dostęp do repozytoriów w innym projekcie, musisz zaktualizować uprawnienia przyznane tokenom dostępu do zadań.

Wyzwalacze ciągłej integracji

Wyzwalacze ciągłej integracji powodują uruchomienie potoku za każdym razem, gdy wypchniesz aktualizację do określonych gałęzi lub wypchniesz określone tagi.

YAML

Potoki YAML są domyślnie konfigurowane z wyzwalaczem ciągłej integracji we wszystkich gałęziach, chyba że ustawienie Wyłącz dorozumianą ci wyzwalacz YAML wprowadzone w przebiegu 227 usługi Azure DevOps jest włączone. Ustawienie Wyłącz dorozumianą ciągłą integrację YAML można skonfigurować na poziomie organizacji lub na poziomie projektu. Po włączeniu ustawienia Wyłącz dorozumianą ci wyzwalacz CI YAML wyzwalacze ciągłej integracji dla potoków YAML nie są włączone, jeśli potok YAML nie ma trigger sekcji. Domyślnie opcja Wyłącz sugerowany wyzwalacz ciągłej integracji YAML nie jest włączona.

Odgałęzienia

Możesz kontrolować, które gałęzie uzyskują wyzwalacze ciągłej integracji za pomocą prostej składni:

trigger:
- main
- releases/*

Możesz określić pełną nazwę gałęzi (na przykład main) lub symbol wieloznaczny (na przykład releases/*). Aby uzyskać informacje na temat składni symboli wieloznacznych, zobacz Symbole wieloznaczne .

Uwaga

Nie można używać zmiennych w wyzwalaczach, ponieważ zmienne są oceniane w czasie wykonywania (po wyzwoleniu wyzwalacza).

Uwaga

Jeśli używasz szablonów do tworzenia plików YAML, możesz określić wyzwalacze tylko w głównym pliku YAML dla potoku. Nie można określić wyzwalaczy w plikach szablonu.

W przypadku bardziej złożonych wyzwalaczy, które używają exclude metody lub batch, należy użyć pełnej składni, jak pokazano w poniższym przykładzie.

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

W powyższym przykładzie potok zostanie wyzwolony, jeśli zostanie wypchnięta zmiana do main lub do dowolnej gałęzi wydania. Nie zostanie jednak wyzwolony, jeśli zostanie wprowadzona zmiana w gałęzi wydań rozpoczynającej się od old.

Jeśli określisz klauzulę exclude bez include klauzuli, jest ona równoważna określeniu * w klauzuli include .

Oprócz określania nazw gałęzi na branches listach można również skonfigurować wyzwalacze na podstawie tagów przy użyciu następującego formatu:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Jeśli nie określono żadnych wyzwalaczy, a ustawienie Wyłącz dorozumianą ci wyzwalacz YAML nie jest włączone, wartość domyślna jest następująca:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Ważne

Po określeniu wyzwalacza zastępuje on domyślny niejawny wyzwalacz i wypycha tylko do gałęzi, które są jawnie skonfigurowane do dołączania, spowoduje wyzwolenie potoku. Uwzględniane są najpierw przetwarzane, a następnie wykluczane są z tej listy.

Wsadowe przebiegi ciągłej integracji

Jeśli często wiele członków zespołu przekazuje zmiany, możesz zmniejszyć liczbę uruchamianych przebiegów. Jeśli ustawiono wartość batch true, gdy potok jest uruchomiony, system czeka na ukończenie przebiegu, a następnie uruchamia kolejny przebieg ze wszystkimi zmianami, które nie zostały jeszcze skompilowane.

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

Uwaga

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

Aby wyjaśnić ten przykład, powiedzmy, że wypychanie A main spowodowało uruchomienie powyższego potoku. Gdy ten potok jest uruchomiony, dodatkowe wypychania B i C występują w repozytorium. Te aktualizacje nie uruchamiają natychmiast nowych niezależnych przebiegów. Jednak po zakończeniu pierwszego uruchomienia wszystkie wypychania do tego momentu są wsadowe razem i jest uruchamiany nowy przebieg.

Uwaga

Jeśli potok ma wiele zadań i etapów, pierwsze uruchomienie powinno nadal osiągać stan terminalu, kończąc lub pomijając wszystkie zadania i etapy przed rozpoczęciem drugiego uruchomienia. Z tego powodu należy zachować ostrożność podczas korzystania z tej funkcji w potoku z wieloma etapami lub zatwierdzeniami. Jeśli chcesz wsadować kompilacje w takich przypadkach, zaleca się podzielenie procesu ciągłej integracji/ciągłego wdrażania na dwa potoki — jeden dla kompilacji (z dzieleniem na partie) i jeden dla wdrożeń.

Ścieżki

Można określić ścieżki plików do uwzględnienia lub wykluczenia.

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

Podczas określania ścieżek należy jawnie określić gałęzie do wyzwolenia, jeśli używasz usługi Azure DevOps Server 2019.1 lub nowszej. Nie można wyzwolić potoku tylko z filtrem ścieżki; Musisz również mieć filtr gałęzi, a zmienione pliki zgodne z filtrem ścieżki muszą pochodzić z gałęzi zgodnej z filtrem gałęzi. Jeśli używasz usługi Azure DevOps Server 2020 lub nowszej, możesz pominąć branches filtrowanie we wszystkich gałęziach w połączeniu z filtrem ścieżki.

Symbole wieloznaczne są obsługiwane w przypadku filtrów ścieżek. Można na przykład uwzględnić wszystkie ścieżki zgodne z src/app/**/myapp*parametrem . Możesz użyć symboli wieloznacznych (**, *, lub ?) podczas określania filtrów ścieżek).

• Ścieżki są zawsze określane względem katalogu głównego repozytorium.
• Jeśli nie ustawisz filtrów ścieżek, folder główny repozytorium jest domyślnie dołączany niejawnie.
• Jeśli wykluczysz ścieżkę, nie można jej również uwzględnić, chyba że kwalifikujesz się do bardziej szczegółowego folderu. Jeśli na przykład wykluczysz /tools, możesz uwzględnić /tools/trigger-runs-on-these
• Kolejność filtrów ścieżek nie ma znaczenia.
• Ścieżki w usłudze Git są wrażliwe na wielkość liter. Pamiętaj, aby użyć tego samego przypadku co rzeczywiste foldery.
• Nie można używać zmiennych w ścieżkach, ponieważ zmienne są oceniane w czasie wykonywania (po wyzwoleniu wyzwalacza).

Tagi

Oprócz określania tagów na branches listach, jak opisano w poprzedniej sekcji, można bezpośrednio określić tagi do uwzględnienia lub wykluczenia:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Jeśli nie określisz żadnych wyzwalaczy tagów, domyślnie tagi nie będą wyzwalać potoków.

Ważne

Jeśli określisz tagi w połączeniu z filtrami gałęzi, wyzwalacz zostanie wyzwolony, jeśli filtr gałęzi jest spełniony lub filtr tagu jest spełniony. Jeśli na przykład tag wypychany spełnia filtr gałęzi, potok jest wyzwalany nawet wtedy, gdy tag jest wykluczony przez filtr tagu, ponieważ wypychanie spełnia filtr gałęzi.

Rezygnacja z ciągłej integracji

Wyłączanie wyzwalacza ciągłej integracji

Możesz całkowicie zrezygnować z wyzwalaczy ciągłej integracji, określając .trigger: none

# A pipeline with no CI trigger
trigger: none

Ważne

Podczas wypychania zmiany do gałęzi plik YAML w tej gałęzi jest oceniany w celu określenia, czy należy uruchomić przebieg ciągłej integracji.

Klasyczny

Wybierz pozycję Włącz ciągłą integrację na karcie Wyzwalacze , aby włączyć ten wyzwalacz, jeśli chcesz, aby kompilacja uruchamiała się za każdym razem, gdy ktoś zaewidencjonuje kod.

Zmiany wsadowe

Zaznacz to pole wyboru, jeśli wielu członków zespołu często przekazuje zmiany i chcesz zmniejszyć liczbę uruchomionych kompilacji. Jeśli wybierzesz tę opcję, gdy kompilacja jest uruchomiona, system czeka na ukończenie przebiegu, a następnie kolejkuje kolejne uruchomienie wszystkich zmian, które nie zostały jeszcze skompilowane.

Możesz wsadować zmiany i tworzyć je razem.

Uwaga

Jeśli używasz przetwarzania wsadowego z wieloetapowym potokiem YAML, uruchomienie musi osiągnąć stan terminalu, zanim będzie można uruchomić następny. Często nie jest to pożądane, ponieważ potok wieloetapowy może przechodzić przez zatwierdzenia i długotrwałe etapy wdrażania. W takich przypadkach zaleca się wykonanie jednego z następujących rozwiązań:

• nie należy używać dzielenia na partie
• podziel potok na dwa oddzielne potoki — jeden dla ciągłej integracji i jeden dysk CD
• ustawianie odpowiednich warunków na etapach, aby pominąć je i szybko zakończyć przebieg

Filtry gałęzi

Możesz określić gałęzie, w których chcesz wyzwalać kompilacje. Jeśli chcesz użyć symboli wieloznacznych, wpisz specyfikację gałęzi (na przykład features/modules/*), a następnie naciśnij Enter.

Filtry ścieżek

Jeśli repozytorium Git znajduje się w usłudze Azure Repos lub TFS, możesz również określić filtry ścieżek, aby zmniejszyć zestaw plików, które chcesz wyzwolić kompilację.

Porady:

• Ścieżki są zawsze określane względem katalogu głównego repozytorium.
• Jeśli nie ustawisz filtrów ścieżek, folder główny repozytorium jest domyślnie dołączany niejawnie.
• Jeśli wykluczysz ścieżkę, nie można jej również uwzględnić, chyba że kwalifikujesz się do bardziej szczegółowego folderu. Jeśli na przykład wykluczysz /tools, możesz uwzględnić /tools/trigger-runs-on-these
• Kolejność filtrów ścieżek nie ma znaczenia.
• Ścieżki w usłudze Git są wrażliwe na wielkość liter. Pamiętaj, aby użyć tego samego przypadku co rzeczywiste foldery.

Przykład

Na przykład chcesz, aby kompilacja została wyzwolona przez zmiany w main gałęziach funkcji i nie wszystkie. Nie chcesz również wyzwalać kompilacji przez zmiany plików w folderze narzędzi.

Pomijanie ciągłej integracji dla poszczególnych wypchnięć

Możesz również poinformować usługę Azure Pipelines, aby pominąć uruchamianie potoku, który zwykle wyzwala wypychanie. Wystarczy dołączyć [skip ci] komunikat lub opis dowolnego zatwierdzenia, które są częścią wypychania, a usługa Azure Pipelines pominą uruchamianie ciągłej integracji dla tego wypychania. Można również użyć dowolnej z następujących odmian.

• [skip ci] lub [ci skip]
• skip-checks: true lub skip-checks:true
• [skip azurepipelines] lub [azurepipelines skip]
• [skip azpipelines] lub [azpipelines skip]
• [skip azp] lub [azp skip]
• ***NO_CI***

Używanie typu wyzwalacza w warunkach

Typowym scenariuszem jest uruchamianie różnych kroków, zadań lub etapów w potoku w zależności od typu wyzwalacza, który uruchomił przebieg. Można to zrobić przy użyciu zmiennej systemowej Build.Reason. Na przykład dodaj następujący warunek do kroku, zadania lub etapu, aby wykluczyć go z walidacji żądania ściągnięcia.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Zachowanie wyzwalaczy podczas tworzenia nowych gałęzi

Często konfiguruje się wiele potoków dla tego samego repozytorium. Na przykład może istnieć jeden potok do skompilowania dokumentacji dla aplikacji, a drugi w celu skompilowania kodu źródłowego. Wyzwalacze ciągłej integracji można skonfigurować przy użyciu odpowiednich filtrów gałęzi i filtrów ścieżek w każdym z tych potoków. Możesz na przykład chcieć wyzwolić jeden potok po wypchnięciu aktualizacji do docs folderu, a drugi do wyzwolenia po wypchnięciu aktualizacji do kodu aplikacji. W takich przypadkach należy zrozumieć, jak potoki są wyzwalane po utworzeniu nowej gałęzi.

Oto zachowanie podczas wypychania nowej gałęzi (zgodnej z filtrami gałęzi) do repozytorium:

• Jeśli potok ma filtry ścieżek, zostanie wyzwolony tylko wtedy, gdy nowa gałąź ma zmiany w plikach pasujących do tego filtru ścieżki.
• Jeśli potok nie ma filtrów ścieżek, zostanie on wyzwolony, nawet jeśli nie ma żadnych zmian w nowej gałęzi.

Symbole wieloznaczne

Podczas określania gałęzi, tagu lub ścieżki można użyć dokładnej nazwy lub symbolu wieloznacznych. Wzorce symboli wieloznacznych umożliwiają * dopasowanie zera lub większej liczby znaków i ? dopasowanie pojedynczego znaku.

• Jeśli zaczniesz od wzorca * w potoku YAML, musisz opakowować wzorzec w cudzysłowie, na przykład "*-releases".
• W przypadku gałęzi i tagów:
  • Symbol wieloznaczny może pojawić się w dowolnym miejscu we wzorcu.
• Dla ścieżek:
  • W usłudze Azure DevOps Server 2022 lub nowszym, w tym w usłudze Azure DevOps Services, symbol wieloznaczny może pojawić się w dowolnym miejscu we wzorcu ścieżki i można go użyć * lub ?.
  • W usłudze Azure DevOps Server 2020 i niższym można dołączyć * go jako końcowy znak, ale nie różni się od samodzielnego określania nazwy katalogu. Nie można uwzględnić * w środku filtru ścieżki i nie można użyć polecenia .?

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

Wyzwalacze żądania ściągnięcia

Wyzwalacze żądania ściągnięcia powodują uruchomienie potoku przy każdym otwarciu żądania ściągnięcia lub wypchnięciu do niego zmian. W usłudze Azure Repos Git ta funkcja jest implementowana przy użyciu zasad gałęzi. Aby włączyć walidację żądania ściągnięcia, przejdź do zasad gałęzi dla żądanej gałęzi i skonfiguruj zasady weryfikacji kompilacji dla tej gałęzi. Aby uzyskać więcej informacji, zobacz Konfigurowanie zasad gałęzi.

Jeśli masz otwarte żądanie ściągnięcia i wypchniesz zmiany do gałęzi źródłowej, może zostać uruchomionych wiele potoków:

• Potoki określone przez zasady weryfikacji kompilacji gałęzi docelowej będą uruchamiane w zatwierdzeniu scalania (scalony kod między gałęziami źródłowymi i docelowymi żądania ściągnięcia), niezależnie od tego, czy istnieją wypchnięte zatwierdzenia, których komunikaty lub opisy zawierają [skip ci] (lub dowolny z jego wariantów).
• Potoki wyzwalane przez zmiany w gałęzi źródłowej żądania ściągnięcia, jeśli nie ma wypchniętych zatwierdzeń, których komunikaty lub opisy zawierają [skip ci] (lub którykolwiek z jego wariantów). Jeśli co najmniej jedno wypchnięte zatwierdzenie zawiera [skip ci], potoki nie będą uruchamiane.

Na koniec po scaleniu żądania ściągnięcia usługa Azure Pipelines uruchomi potoki ciągłej integracji wyzwalane przez wypchnięcie do gałęzi docelowej, nawet jeśli niektóre scalone komunikaty lub opisy zatwierdzeń zawierają [skip ci] (lub dowolny z jego wariantów).

Uwaga

Aby skonfigurować kompilacje weryfikacji dla repozytorium Git usługi Azure Repos, musisz być administratorem projektu.

Uwaga

Żądania ściągnięcia wersji roboczej nie wyzwalają potoku nawet w przypadku skonfigurowania zasad gałęzi.

Weryfikowanie współtworzenia z rozwidleń

Tworzenie żądań ściągnięcia z rozwidlenia usługi Azure Repos nie różni się od kompilowania żądań ściągnięcia w tym samym repozytorium lub projekcie. Rozwidlenia można tworzyć tylko w tej samej organizacji, w której znajduje się projekt.

Ograniczanie zakresu autoryzacji zadania

Usługa Azure Pipelines udostępnia kilka ustawień zabezpieczeń w celu skonfigurowania zakresu autoryzacji zadania, za pomocą którego są uruchamiane potoki.

• Ogranicz zakres autoryzacji zadania do bieżącego projektu
• Ochrona dostępu do repozytoriów w potokach YAML

Ogranicz zakres autoryzacji zadania do bieżącego projektu

Usługa Azure Pipelines udostępnia dwa zakres autoryzacji zadania limitu do bieżących ustawień projektu :

• Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków innych niż wydania — to ustawienie dotyczy potoków YAML i klasycznych potoków kompilacji. To ustawienie nie ma zastosowania do klasycznych potoków wydania.
• Ogranicz zakres autoryzacji zadań do bieżącego projektu dla potoków wydania — to ustawienie dotyczy tylko klasycznych potoków wydania.

Potoki są uruchamiane z tokenami dostępu w zakresie kolekcji, chyba że jest włączone odpowiednie ustawienie dla typu potoku. Ustawienia zakresu autoryzacji zadania Limit umożliwiają zmniejszenie zakresu dostępu dla wszystkich potoków do bieżącego projektu. Może to mieć wpływ na potok, jeśli uzyskujesz dostęp do repozytorium Git usługi Azure Repos w innym projekcie w organizacji.

Jeśli repozytorium Git usługi Azure Repos znajduje się w innym projekcie niż potok, a ustawienie Limit zakresu autoryzacji zadania dla typu potoku jest włączone, musisz udzielić uprawnień do tożsamości usługi kompilacji dla potoku w drugim projekcie. Aby uzyskać więcej informacji, zobacz Zarządzanie uprawnieniami konta usługi kompilacji.

Aby uzyskać więcej informacji na temat limitu zakresu autoryzacji zadania, zobacz Omówienie tokenów dostępu do zadań.

Ochrona dostępu do repozytoriów w potokach YAML

Potoki mogą uzyskiwać dostęp do dowolnych repozytoriów usługi Azure DevOps w autoryzowanych projektach, zgodnie z opisem w poprzedniej sekcji Ograniczanie zakresu autoryzacji zadania do bieżącego projektu , chyba że włączono ochronę dostępu do repozytoriów w potokach YAML. Po włączeniu tej opcji można zmniejszyć zakres dostępu dla wszystkich potoków tylko do repozytoriów usługi Azure DevOps, do których jawnie odwołuje się checkout krok lub uses instrukcja w zadaniu potoku, które używa tego repozytorium.

Aby skonfigurować to ustawienie, przejdź do pozycji Potoki, Ustawienia w obszarze Ustawienia organizacji lub Ustawienia projektu. Jeśli ustawienie jest włączone na poziomie organizacji, jest wyszarywane i niedostępne na poziomie ustawień projektu.

Ważne

Ochrona dostępu do repozytoriów w potokach YAML jest domyślnie włączona dla nowych organizacji i projektów utworzonych po maju 2020 r. Po włączeniu funkcji Ochrona dostępu do repozytoriów w potokach YAML potoki YAML muszą jawnie odwoływać się do wszystkich repozytoriów Git usługi Azure Repos, których chcesz użyć w potoku jako kroku wyewidencjonowania w zadaniu używającym repozytorium. Nie będzie można pobrać kodu przy użyciu zadań skryptowych i poleceń git dla repozytorium Git usługi Azure Repos, chyba że to repozytorium zostanie jawnie przywołyane.

Istnieje kilka wyjątków, w których nie trzeba jawnie odwoływać się do repozytorium Git usługi Azure Repos przed użyciem go w potoku, gdy jest włączona ochrona dostępu do repozytoriów w potokach YAML.

• Jeśli nie masz jawnego kroku wyewidencjonowania w potoku, jest to tak, jakby masz checkout: self krok, a self repozytorium zostało wyewidencjonowane.
• Jeśli używasz skryptu do wykonywania operacji tylko do odczytu w repozytorium w projekcie publicznym, nie musisz odwoływać się do publicznego repozytorium projektu w kroku checkout .
• Jeśli używasz skryptu, który udostępnia własne uwierzytelnianie w repozytorium, takim jak pat, nie musisz odwoływać się do tego repozytorium w kroku checkout .

Na przykład gdy włączono ochronę dostępu do repozytoriów w potokach YAML, jeśli potok znajduje się w FabrikamProject/Fabrikam repozytorium w organizacji i chcesz użyć skryptu do wyewidencjonowania FabrikamProject/FabrikamTools repozytorium, musisz odwołać się do tego repozytorium w checkout kroku lub za uses pomocą instrukcji .

Jeśli już wyewidencjonujesz FabrikamTools repozytorium w potoku przy użyciu kroku wyewidencjonowania, możesz następnie użyć skryptów do interakcji z tym repozytorium.

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

Uwaga

W wielu scenariuszach można wykorzystać wyewidencjonowanie wielu repozytoriów, co spowoduje usunięcie konieczności użycia skryptów w celu wyewidencjonowania dodatkowych repozytoriów w potoku. Aby uzyskać więcej informacji, zobacz Sprawdzanie wielu repozytoriów w potoku.

Finalizuj

Po wyzwoleniu potoku usługa Azure Pipelines ściąga kod źródłowy z repozytorium Git usługi Azure Repos. Możesz kontrolować różne aspekty tego, jak to się dzieje.

Uwaga

Po dołączeniu kroku wyewidencjonowania w potoku uruchomimy następujące polecenie: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin --depth=1. Jeśli nie spełnia to Twoich potrzeb, możesz wykluczyć wbudowane wyewidencjonowania checkout: none , a następnie użyć zadania skryptu do wykonania własnych wyewidencjonowania.

Preferowana wersja usługi Git

Agent systemu Windows jest dostarczany z własną kopią narzędzia Git. Jeśli wolisz podać własną usługę Git, a nie użyć dołączonej kopii, ustaw wartość System.PreferGitFromPath .true To ustawienie jest zawsze prawdziwe w przypadku agentów innych niż Windows.

Ścieżka wyewidencjonowania

YAML

Jeśli domyślnie wyewidencjonujesz pojedyncze repozytorium, kod źródłowy zostanie wyewidencjonowany w katalogu o nazwie s. W przypadku potoków YAML można to zmienić, określając element za pomocą checkout elementu path. Określona ścieżka jest względna do $(Agent.BuildDirectory). Na przykład: jeśli wartość ścieżki wyewidencjonowania to mycustompath i $(Agent.BuildDirectory) ma C:\agent\_work\1wartość , kod źródłowy zostanie wyewidencjonowany w pliku C:\agent\_work\1\mycustompath.

Jeśli używasz wielu checkout kroków i wyewidencjonujesz wiele repozytoriów, a nie jawnie określasz folderu przy użyciu polecenia path, każde repozytorium zostanie umieszczone w podfolderze nazwanym s po repozytorium. Jeśli na przykład wyewidencjonujesz dwa repozytoria o nazwie tools i code, kod źródłowy zostanie wyewidencjonowany w C:\agent\_work\1\s\tools systemach i C:\agent\_work\1\s\code.

Należy pamiętać, że nie można ustawić wartości ścieżki wyewidencjonowania, aby przejść w górę poziomów katalogów powyżej $(Agent.BuildDirectory), więc path\..\anotherpath spowoduje to prawidłową ścieżkę wyewidencjonowania (tj. C:\agent\_work\1\anotherpath), ale wartość taka jak ..\invalidpath nie (tj. C:\agent\_work\invalidpath).

Ustawienie można skonfigurować path w kroku wyewidencjonowania potoku.

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

Klasyczny

To ustawienie nie jest konfigurowalne w edytorze klasycznym. Kod źródłowy zostanie wyewidencjonowany w katalogu o nazwie s, który jest powiązany z $(Agent.BuildDirectory). Na przykład: jeśli $(Agent.BuildDirectory) ma wartość C:\agent\_work\1, kod źródłowy zostanie wyewidencjonowany w pliku C:\agent\_work\1\mycustompath.

Podmoduły

YAML

Ustawienie można skonfigurować submodules w kroku wyewidencjonowania potoku, jeśli chcesz pobrać pliki z modułów podrzędnych.

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

Klasyczny

Ustawienie Moduły podrzędne można skonfigurować z właściwości zadania Pobierz źródła w potoku, jeśli chcesz pobrać pliki z modułów podrzędnych.

Potok kompilacji wyewidencjonuje podmoduły usługi Git, o ile są:

• Nieuwierzytelnione: publiczne, nieuwierzytelnione repozytorium bez poświadczeń wymaganych do klonowania lub pobierania.

• Uwierzytelniony:

  • Zawarte w tym samym projekcie co repozytorium Git usługi Azure Repos określone powyżej. Te same poświadczenia, które są używane przez agenta do pobierania źródeł z repozytorium głównego, są również używane do pobierania źródeł dla modułów podrzędnych.

  • Dodano przy użyciu adresu URL względem repozytorium głównego. Na przykład

    • Ten zostanie wyewidencjonowany: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

      W tym przykładzie moduł podrzędny odwołuje się do repozytorium (FabrikamFiber) w tej samej organizacji usługi Azure DevOps, ale w innym projekcie (FabrikamFiberProject). Te same poświadczenia, które są używane przez agenta do pobierania źródeł z repozytorium głównego, są również używane do pobierania źródeł dla modułów podrzędnych. Wymaga to, aby token dostępu do zadania miał dostęp do repozytorium w drugim projekcie. Jeśli token dostępu do zadania został ograniczony zgodnie z opisem w powyższej sekcji, nie będzie można tego zrobić. Token dostępu do zadania można zezwolić na dostęp do repozytorium w drugim projekcie przez jawne udzielenie dostępu do konta usługi kompilacji projektu w drugim projekcie lub (b) przy użyciu tokenów dostępu w zakresie kolekcji zamiast tokenów o zakresie projektu dla całej organizacji. Aby uzyskać więcej informacji na temat tych opcji i ich wpływu na zabezpieczenia, zobacz Access repozytoria, artefakty i inne zasoby.

    • Ten nie zostanie wyewidencjonowany: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

Alternatywa dla opcji wyewidencjonowania modułów podrzędnych

W niektórych przypadkach nie można użyć opcji Wyewidencjonuj moduły podrzędne . Może istnieć scenariusz, w którym potrzebny jest inny zestaw poświadczeń w celu uzyskania dostępu do modułów podrzędnych. Może się to zdarzyć, na przykład jeśli repozytorium główne i repozytoria modułów podrzędnych nie są przechowywane w tej samej organizacji usługi Azure DevOps lub jeśli token dostępu do zadania nie ma dostępu do repozytorium w innym projekcie.

Jeśli nie możesz użyć opcji Wyewidencjonuj moduły podrzędne , możesz zamiast tego użyć niestandardowego kroku skryptu, aby pobrać moduły podrzędne. Najpierw uzyskaj osobisty token dostępu (PAT) i prefiks za pomocą pat:polecenia . Następnie zakoduj ten prefiksowy ciąg base64, aby utworzyć podstawowy token uwierzytelniania. Na koniec dodaj ten skrypt do potoku:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: Basic <BASE64_ENCODED_STRING>" submodule update --init --recursive

Pamiętaj, aby zastąpić ciąg "<BASE64_ENCODED_STRING>" ciągiem "pat:token" zakodowanym w formacie Base64.

Użyj zmiennej tajnej w projekcie lub potoku kompilacji, aby przechowywać wygenerowany podstawowy token uwierzytelniania. Użyj tej zmiennej, aby wypełnić wpis tajny w powyższym poleceniu git.

Uwaga

.: Dlaczego nie mogę użyć menedżera poświadczeń Git w agencie? A: Przechowywanie poświadczeń modułu podrzędnego w menedżerze poświadczeń usługi Git zainstalowanym na prywatnym agencie kompilacji zwykle nie jest skuteczne, ponieważ menedżer poświadczeń może monitować o ponowne wprowadzenie poświadczeń za każdym razem, gdy moduł podrzędny zostanie zaktualizowany. Nie jest to pożądane podczas automatycznych kompilacji, gdy interakcja użytkownika nie jest możliwa.

Synchronizowanie tagów

Ważne

Funkcja tagów synchronizacji jest obsługiwana w usłudze Azure Repos Git z programem Azure DevOps Server 2022.1 lub nowszym.

Krok wyewidencjonowania używa --tags opcji podczas pobierania zawartości repozytorium Git. Powoduje to pobranie wszystkich tagów przez serwer oraz wszystkich obiektów wskazywanych przez te tagi. Zwiększa to czas uruchamiania zadania w potoku, szczególnie jeśli masz duże repozytorium z wieloma tagami. Ponadto krok wyewidencjonowania synchronizuje tagi nawet po włączeniu płytkiej opcji pobierania, co może oznaczać pokonanie jego celu. Aby zmniejszyć ilość danych pobranych lub ściągniętych z repozytorium Git, firma Microsoft dodała nową opcję wyewidencjonowania w celu kontrolowania zachowania synchronizacji tagów. Ta opcja jest dostępna zarówno w potokach klasycznych, jak i YAML.

Czy synchronizować tagi podczas wyewidencjonowania repozytorium można skonfigurować w języku YAML, ustawiając fetchTags właściwość i w interfejsie użytkownika, konfigurując ustawienie Tagi synchronizacji.

YAML

Ustawienie można skonfigurować fetchTags w kroku wyewidencjonowania potoku.

Aby skonfigurować ustawienie w języku YAML, ustaw fetchTags właściwość .

steps:
- checkout: self
  fetchTags: true

To ustawienie można również skonfigurować przy użyciu opcji Synchronizuj tagi w interfejsie użytkownika ustawień potoku.

1. Edytuj potok YAML i wybierz pozycję Więcej akcji Wyzwalacze.

   

2. Wybierz pozycję YAML, Pobierz źródła.

   

3. Skonfiguruj ustawienie Synchronizuj tagi.

   

Uwaga

Jeśli jawnie ustawisz fetchTags w checkout kroku, to ustawienie ma priorytet nad ustawieniem skonfigurowanym w interfejsie użytkownika ustawień potoku.

Klasyczny

Ustawienie Tagi synchronizacji można skonfigurować z właściwości zadania Pobierz źródła w potoku.

Zachowanie domyślne

• W przypadku istniejących potoków utworzonych przed wydaniem przebiegu usługi Azure DevOps 209, wydanego we wrześniu 2022 r., ustawienie domyślne dla tagów synchronizacji pozostaje takie samo jak istniejące zachowanie przed dodaniu opcji Tagów synchronizacji, czyli true.
• W przypadku nowych potoków utworzonych po uruchomieniu przebiegu usługi Azure DevOps w wersji 209 domyślną wartością tagów synchronizacji jest false.

Uwaga

Jeśli jawnie ustawisz fetchTags w checkout kroku, to ustawienie ma priorytet nad ustawieniem skonfigurowanym w interfejsie użytkownika ustawień potoku.

Płytkie pobieranie

Możesz ograniczyć, jak daleko w historii do pobrania. Skutecznie powoduje to wyświetlenie polecenia git fetch --depth=n. Jeśli repozytorium jest duże, ta opcja może zwiększyć wydajność potoku kompilacji. Repozytorium może być duże, jeśli jest ono używane przez długi czas i ma możliwą do rozmiaru historię. Może to być również duże, jeśli dodano i później usunięto duże pliki.

Ważne

Nowe potoki utworzone po aktualizacji przebiegu usługi Azure DevOps z września 2022 r. mają domyślnie włączone płytkie pobieranie i skonfigurowane z głębokością 1. Wcześniej ustawieniem domyślnym nie było płytkie pobieranie. Aby sprawdzić potok, wyświetl ustawienie Płytkie pobieranie w interfejsie użytkownika ustawień potoku zgodnie z opisem w poniższej sekcji.

YAML

Ustawienie można skonfigurować fetchDepth w kroku wyewidencjonowania potoku.

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

Możesz również skonfigurować głębokość pobierania, ustawiając opcję Płytkia głębokość w interfejsie użytkownika ustawień potoku.

1. Edytuj potok YAML i wybierz pozycję Więcej akcji Wyzwalacze.

   

2. Wybierz pozycję YAML, Pobierz źródła.

   

3. Skonfiguruj ustawienie Płytkie pobieranie. Usuń zaznaczenie płytkiego pobierania , aby wyłączyć płytkie pobieranie, lub zaznacz pole wyboru i wprowadź głębokość , aby włączyć płytkie pobieranie.

   

Uwaga

Jeśli jawnie ustawisz fetchDepth w checkout kroku, to ustawienie ma priorytet nad ustawieniem skonfigurowanym w interfejsie użytkownika ustawień potoku. Ustawienie fetchDepth: 0 pobiera całą historię i zastępuje ustawienie Płytkie pobieranie .

Klasyczny

Ustawienie Płytkie pobieranie można skonfigurować z właściwości zadania Pobierz źródła w potoku.

W takich przypadkach ta opcja może pomóc w oszczędzaniu zasobów sieciowych i magazynowych. Może to również zaoszczędzić czas. Powodem, dla którego nie zawsze jest oszczędność czasu, jest to, że w niektórych sytuacjach serwer może potrzebować czasu na obliczanie zatwierdzeń do pobrania dla określonej głębokości.

Uwaga

Po uruchomieniu potoku gałąź do kompilacji jest rozpoznawana jako identyfikator zatwierdzenia. Następnie agent pobiera gałąź i sprawdza żądane zatwierdzenie. Istnieje małe okno między usunięciem gałęzi z identyfikatorem zatwierdzenia i wykonaniem wyewidencjonowania przez agenta. Jeśli gałąź zostanie zaktualizowana szybko i ustawisz bardzo małą wartość dla płytkiego pobierania, zatwierdzenie może nie istnieć, gdy agent spróbuje go wyewidencjonować. W takim przypadku zwiększ płytkie ustawienie głębokości pobierania.

Nie synchronizuj źródeł

Możesz pominąć pobieranie nowych zatwierdzeń. Ta opcja może być przydatna w przypadkach, gdy chcesz:

• Narzędzie Git init, konfiguracja i pobieranie przy użyciu własnych opcji niestandardowych.

• Użyj potoku kompilacji, aby po prostu uruchomić automatyzację (na przykład niektóre skrypty), które nie zależą od kodu w kontroli wersji.

YAML

Możesz skonfigurować ustawienie Nie synchronizuj źródeł w kroku wyewidencjonowania potoku, ustawiając wartość checkout: none.

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

Klasyczny

Wybierz ustawienie Nie synchronizuj źródeł z właściwości zadania Pobierz źródła w potoku.

Uwaga

Jeśli używasz tej opcji, agent pomija również uruchamianie poleceń Git, które czyszczą repozytorium.

Czyszczenie kompilacji

Przed uruchomieniem kompilacji można wykonać różne formy czyszczenia katalogu roboczego własnego agenta.

Ogólnie rzecz biorąc, aby zapewnić szybszą wydajność własnych agentów, nie usuwaj repozytorium. W tym przypadku, aby uzyskać najlepszą wydajność, upewnij się, że kompilujesz również przyrostowo, wyłączając dowolną opcję Wyczyść zadania lub narzędzia używanego do kompilowania.

Jeśli musisz wyczyścić repozytorium (na przykład uniknąć problemów spowodowanych przez pliki reszt z poprzedniej kompilacji), dostępne są poniższe opcje.

Uwaga

Czyszczenie nie jest skuteczne, jeśli używasz agenta hostowanego przez firmę Microsoft, ponieważ za każdym razem otrzymasz nowego agenta.

YAML

Ustawienie można skonfigurować clean w kroku wyewidencjonowania potoku.

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

Gdy clean parametr jest ustawiony na true potok kompilacji, wykonuje cofanie wszelkich zmian w pliku $(Build.SourcesDirectory). W szczególności następujące polecenia git są wykonywane przed pobraniem źródła.

git clean -ffdx
git reset --hard HEAD

Aby uzyskać więcej opcji, można skonfigurować workspace ustawienie zadania.

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

Zapewnia to następujące czyste opcje.

• dane wyjściowe: ta sama operacja co ustawienie czyszczenia opisane w poprzednim zadaniu wyewidencjonowania oraz: Usuwa i ponownie odtwarza $(Build.BinariesDirectory)element . Należy pamiętać, że i $(Build.ArtifactStagingDirectory) $(Common.TestResultsDirectory) są zawsze usuwane i tworzone ponownie przed każdą kompilacją niezależnie od dowolnego z tych ustawień.

• resources: Usuwa i ponownie utworzy $(Build.SourcesDirectory)element . Spowoduje to zainicjowanie nowego lokalnego repozytorium Git dla każdej kompilacji.

• all: Usuwa i ponownie utworzy $(Agent.BuildDirectory)element . Spowoduje to zainicjowanie nowego lokalnego repozytorium Git dla każdej kompilacji.

Klasyczny

Wybierz ustawienie Clean (Czyszczenie) z właściwości zadania Pobierz źródła w potoku i wybierz jedną z następujących opcji.

• Źródła: potok kompilacji wykonuje cofanie wszelkich zmian w pliku $(Build.SourcesDirectory). W szczególności następujące polecenia git są wykonywane przed pobraniem źródła.

  git clean -ffdx
  git reset --hard HEAD
  

• Źródła i katalog wyjściowy: ta sama operacja co opcja Źródła powyżej, a także: Usuwa i odtwarza $(Build.BinariesDirectory)element . Należy pamiętać, że i $(Build.ArtifactStagingDirectory) $(Common.TestResultsDirectory) są zawsze usuwane i tworzone ponownie przed każdą kompilacją niezależnie od dowolnego z tych ustawień.

• Katalog źródeł: usuwa i odtwarza $(Build.SourcesDirectory)plik . Spowoduje to zainicjowanie nowego lokalnego repozytorium Git dla każdej kompilacji.

• Wszystkie katalogi kompilacji: usuwa i tworzy $(Agent.BuildDirectory)ponownie plik . Spowoduje to zainicjowanie nowego lokalnego repozytorium Git dla każdej kompilacji.

Źródła etykiet

Możesz oznaczyć etykiety plikami kodu źródłowego, aby umożliwić zespołowi łatwe zidentyfikowanie wersji każdego pliku zawartego w ukończonej kompilacji. Istnieje również możliwość określenia, czy kod źródłowy powinien być oznaczony etykietą dla wszystkich kompilacji, czy tylko w przypadku pomyślnych kompilacji.

YAML

Obecnie nie można skonfigurować tego ustawienia w języku YAML, ale można go w edytorze klasycznym. Podczas edytowania potoku YAML możesz uzyskać dostęp do edytora klasycznego, wybierając pozycję Wyzwalacze z menu edytora YAML.

W edytorze klasycznym wybierz pozycję YAML, wybierz zadanie Pobierz źródła , a następnie skonfiguruj odpowiednie właściwości.

Klasyczny

Ustawienie Źródła tagów można skonfigurować z właściwości zadania Pobierz źródła w potoku.

W formacie Tag można użyć zmiennych zdefiniowanych przez użytkownika i wstępnie zdefiniowanych, które mają zakres "Wszystkie". Na przykład:

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

Pierwsze cztery zmienne są wstępnie zdefiniowane. My.Variable Można go zdefiniować na karcie zmiennych.

Potok kompilacji etykietuje źródła za pomocą tagu Git.

Niektóre zmienne kompilacji mogą zwracać wartość, która nie jest prawidłową etykietą. Na przykład zmienne, takie jak $(Build.RequestedFor) i $(Build.DefinitionName) mogą zawierać białe znaki. Jeśli wartość zawiera biały znak, tag nie zostanie utworzony.

Po otagowaniu źródeł przez potok kompilacji artefakt z ref usługi Git refs/tags/{tag} zostanie automatycznie dodany do ukończonej kompilacji. Zapewnia to zespołowi dodatkową możliwość śledzenia i bardziej przyjazny dla użytkownika sposób przechodzenia z kompilacji do utworzonego kodu. Tag jest uważany za artefakt kompilacji, ponieważ jest generowany przez kompilację. Jeśli kompilacja zostanie usunięta ręcznie lub za pomocą zasad przechowywania, tag zostanie również usunięty.

Często zadawane pytania

Problemy związane z integracją usługi Azure Repos należą do trzech kategorii:

• Wyzwalacze zakończone niepowodzeniem: mój potok nie jest wyzwalany podczas wypychania aktualizacji do repozytorium.
• Wyewidencjonowanie zakończone niepowodzeniem: mój potok jest wyzwalany, ale kończy się niepowodzeniem w kroku wyewidencjonowania.
• Nieprawidłowa wersja: Mój potok jest uruchamiany, ale używa nieoczekiwanej wersji źródła/YAML.

Wyzwalacze zakończone niepowodzeniem

Właśnie utworzono nowy potok YAML z wyzwalaczami ciągłej integracji/żądania ściągnięcia, ale potok nie jest wyzwalany.

Wykonaj poszczególne z tych kroków, aby rozwiązać problemy z wyzwalaczami zakończonymi niepowodzeniem:

• Czy wyzwalacze ciągłej integracji lub żądania ściągnięcia YAML są zastępowane przez ustawienia potoku w interfejsie użytkownika? Podczas edytowania potoku wybierz pozycję ... a następnie pozycję Wyzwalacze.

  

  Sprawdź ustawienie Zastąp wyzwalacz YAML z tego miejsca dla typów wyzwalacza (ciągła integracja lub walidacja żądania ściągnięcia) dostępnych dla repozytorium.

  

• Czy konfigurujesz wyzwalacz żądania ściągnięcia w pliku YAML lub w zasadach gałęzi dla repozytorium? W przypadku repozytorium Git usługi Azure Repos nie można skonfigurować wyzwalacza żądania ściągnięcia w pliku YAML. Należy użyć zasad gałęzi.

• Czy potok jest wstrzymany lub wyłączony? Otwórz edytor potoku, a następnie wybierz pozycję Ustawienia , aby sprawdzić. Jeśli potok jest wstrzymany lub wyłączony, wyzwalacze nie działają.

• Czy plik YAML został zaktualizowany w odpowiedniej gałęzi? Jeśli wypchniesz aktualizację do gałęzi, plik YAML w tej samej gałęzi zarządza zachowaniem ciągłej integracji. Jeśli wypchniesz aktualizację do gałęzi źródłowej, plik YAML wynikający z scalenia gałęzi źródłowej z gałęzią docelową zarządza zachowaniem żądania ściągnięcia. Upewnij się, że plik YAML w odpowiedniej gałęzi ma wymaganą konfigurację ciągłej integracji lub żądania ściągnięcia.

• Czy wyzwalacz został poprawnie skonfigurowany? Podczas definiowania wyzwalacza YAML można określić zarówno klauzule dołączania, jak i wykluczania dla gałęzi, tagów i ścieżek. Upewnij się, że klauzula include jest zgodna ze szczegółami zatwierdzenia i że klauzula wykluczania nie wyklucza ich. Sprawdź składnię wyzwalaczy i upewnij się, że jest ona dokładna.

• Czy użyto zmiennych podczas definiowania wyzwalacza lub ścieżek? To nie jest obsługiwane.

• Czy używasz szablonów dla pliku YAML? Jeśli tak, upewnij się, że wyzwalacze są zdefiniowane w głównym pliku YAML. Wyzwalacze zdefiniowane wewnątrz plików szablonów nie są obsługiwane.

• Czy wykluczyno gałęzie lub ścieżki, do których wypchnięliśmy zmiany? Przetestuj, wypychając zmianę do dołączonej ścieżki w dołączonej gałęzi. Należy pamiętać, że w wyzwalaczach uwzględniana jest wielkość liter. Podczas określania ścieżek w wyzwalaczach upewnij się, że używasz tego samego przypadku co foldery rzeczywiste.

• Czy po prostu wypchnięliśmy nową gałąź? Jeśli tak, nowa gałąź może nie uruchomić nowego przebiegu. Zobacz sekcję "Zachowanie wyzwalaczy podczas tworzenia nowych gałęzi".

Moje wyzwalacze ciągłej integracji lub żądania ściągnięcia działają prawidłowo. Ale przestali teraz pracować.

Najpierw zapoznaj się z krokami rozwiązywania problemów w poprzednim pytaniu. Następnie wykonaj następujące dodatkowe kroki:

• Czy masz konflikty scalania w żądaniu ściągnięcia? W przypadku żądania ściągnięcia, które nie wyzwoliło potoku, otwórz go i sprawdź, czy ma konflikt scalania. Rozwiąż konflikt scalania.

• Czy występuje opóźnienie przetwarzania zdarzeń wypychania lub żądania ściągnięcia? Zazwyczaj można to sprawdzić, sprawdzając, czy problem jest specyficzny dla pojedynczego potoku lub jest wspólny dla wszystkich potoków lub repozytoriów w projekcie. Jeśli wypychanie lub aktualizacja żądania ściągnięcia do dowolnego repozytorium wykazuje ten objaw, mogą wystąpić opóźnienia w przetwarzaniu zdarzeń aktualizacji. Sprawdź, czy na naszej stronie stanu występuje awaria usługi. Jeśli na stronie stanu jest wyświetlany problem, nasz zespół musi już rozpocząć pracę nad nim. Sprawdź stronę często pod kątem aktualizacji problemu.

Nie chcę, aby użytkownicy zastąpili listę gałęzi wyzwalaczy podczas aktualizowania pliku YAML. W jaki sposób to zrobić?

Użytkownicy z uprawnieniami do współtworzenia kodu mogą aktualizować plik YAML i dołączać/wykluczać dodatkowe gałęzie. W związku z tym użytkownicy mogą uwzględnić własną funkcję lub gałąź użytkownika w pliku YAML i wypchnąć tę aktualizację do funkcji lub gałęzi użytkownika. Może to spowodować wyzwolenie potoku dla wszystkich aktualizacji tej gałęzi. Jeśli chcesz zapobiec temu zachowaniu, możesz:

1. Edytuj potok w interfejsie użytkownika usługi Azure Pipelines.
2. Przejdź do menu Wyzwalacze .
3. Wybierz pozycję Zastąpij wyzwalacz ciągłej integracji YAML z tego miejsca.
4. Określ gałęzie do uwzględnienia lub wykluczenia dla wyzwalacza.

Podczas wykonywania tych kroków wszystkie wyzwalacze ciągłej integracji określone w pliku YAML są ignorowane.

Mam wiele repozytoriów w potoku YAML. Jak mogę skonfigurować wyzwalacze dla każdego repozytorium?

Zobacz informacje o wyzwalaczach w temacie Używanie wielu repozytoriów.

Nieudane wyewidencjonowanie

Podczas kroku wyewidencjonowania jest wyświetlany następujący błąd w pliku dziennika. Jak mogę rozwiązać ten problem?

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

Wykonaj poszczególne z tych kroków, aby rozwiązać problemy z niepowodzeniem wyewidencjonowania:

• Czy repozytorium nadal istnieje? Najpierw upewnij się, że działa, otwierając go na stronie Repozytoria .

• Czy uzyskujesz dostęp do repozytorium przy użyciu skryptu? Jeśli tak, sprawdź ustawienie Ogranicz zakres autoryzacji zadania do przywoływanych repozytoriów usługi Azure DevOps. Jeśli włączono ograniczenie zakresu autoryzacji zadań do odwołań do repozytoriów usługi Azure DevOps, nie będzie można wyewidencjonować repozytoriów Git usługi Azure Repos przy użyciu skryptu, chyba że zostały jawnie przywoływalne jako pierwsze w potoku.

• Jaki jest zakres autoryzacji zadania potoku?

  • Jeśli zakres to kolekcja:

    • Może to być sporadyczne błędy. Uruchom ponownie potok.
    • Ktoś mógł usunąć dostęp do konta usługi Project Collection Build Service.
      • Przejdź do obszaru Project settings for the project (Ustawienia projektu), w którym istnieje repozytorium. Wybierz pozycję Repozytoria > repozytoriów specyficznych > dla repozytoriów, a następnie pozycję Zabezpieczenia.
      • Sprawdź, czy usługa kompilacji kolekcji projektów (twoja nazwa-kolekcja) istnieje na liście użytkowników.
      • Sprawdź, czy to konto ma tag Utwórz i Dostęp do odczytu.

  • Jeśli zakres to projekt:

    • Czy repozytorium znajduje się w tym samym projekcie co potok?
      • Tak:
        • Może to być sporadyczne błędy. Uruchom ponownie potok.
        • Ktoś mógł usunąć dostęp do konta usługi Project Build Service.
          • Przejdź do obszaru Project settings for the project (Ustawienia projektu), w którym istnieje repozytorium. Wybierz pozycję Repozytoria > repozytoriów specyficznych > dla repozytoriów, a następnie pozycję Zabezpieczenia.
          • Sprawdź, czy usługa kompilacji nazwa projektu (nazwa-kolekcji) istnieje na liście użytkowników.
          • Sprawdź, czy to konto ma tag Utwórz i Dostęp do odczytu.
      • Nie:
        • Czy potok jest w projekcie publicznym?
          • Tak: nie można uzyskać dostępu do zasobów spoza projektu publicznego. Ustaw projekt jako prywatny.
          • Nie: musisz skonfigurować uprawnienia dostępu do innego repozytorium w tej samej kolekcji projektów.

Nieprawidłowa wersja

W potoku jest używana nieprawidłowa wersja pliku YAML. Dlaczego?

• W przypadku wyzwalaczy ciągłej integracji plik YAML, który znajduje się w wypychanej gałęzi, jest oceniany, aby sprawdzić, czy powinna zostać uruchomiona kompilacja ciągłej integracji.
• W przypadku wyzwalaczy żądania ściągnięcia plik YAML wynikający z scalenia gałęzi źródłowych i docelowych żądania ściągnięcia jest oceniany, aby sprawdzić, czy powinna zostać uruchomiona kompilacja żądania ściągnięcia.

Powiązane artykuły

• Zaplanowane wyzwalacze
• Wyzwalacze ukończenia potoku