Udostępnij za pośrednictwem

Tworzenie repozytoriów GitHub

  • Artykuł

Azure DevOps Services

Usługa Azure Pipelines może automatycznie kompilować i weryfikować każde żądanie ściągnięcia i zatwierdzać je w repozytorium GitHub. W tym artykule opisano sposób konfigurowania integracji między usługami GitHub i Azure Pipelines.

Jeśli dopiero zaczynasz korzystać z integracji potoków z usługą GitHub, wykonaj kroki opisane w temacie Tworzenie pierwszego potoku. Wróć do tego artykułu, aby dowiedzieć się więcej na temat konfigurowania i dostosowywania integracji między usługami GitHub i Azure Pipelines.

Organizacje i użytkownicy

Usługi GitHub i Azure Pipelines to dwie niezależne usługi, które dobrze się integrują. Każdy z nich ma własną organizację i zarządzanie użytkownikami. Ta sekcja zawiera zalecenie dotyczące replikowania organizacji i użytkowników z usługi GitHub do usługi Azure Pipelines.

Organizacje

Struktura usługi GitHub składa się z organizacji i kont użytkowników, które zawierają repozytoria. Zobacz dokumentację usługi GitHub.

Struktura organizacji usługi GitHub

Struktura usługi Azure DevOps składa się z organizacji , które zawierają projekty. Zobacz Planowanie struktury organizacyjnej.

Struktura organizacji usługi Azure DevOps

Usługa Azure DevOps może odzwierciedlać strukturę usługi GitHub za pomocą:

  • Organizacja DevOps dla organizacji lub konta użytkownika usługi GitHub
  • Usługa DevOps Projects dla repozytoriów GitHub

Struktura usługi GitHub mapowana na usługę Azure DevOps

Aby skonfigurować identyczną strukturę w usłudze Azure DevOps:

  1. Utwórz organizację DevOps o nazwie po organizacji lub koncie użytkownika usługi GitHub. Będzie on miał adres URL, taki jak https://dev.azure.com/your-organization.
  2. W organizacji DevOps utwórz projekty o nazwie po repozytoriach. Będą one miały adresy URL, takie jak https://dev.azure.com/your-organization/your-repository.
  3. W projekcie DevOps utwórz potoki o nazwie od organizacji GitHub i repozytorium, które tworzą, takie jak your-organization.your-repository. Następnie jest jasne, dla których repozytoriów są przeznaczone.

Zgodnie z tym wzorcem repozytoria GitHub i usługi Azure DevOps Projects będą miały pasujące ścieżki adresu URL. Na przykład:

Usługa URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Użytkownicy

Użytkownicy usługi GitHub nie uzyskują automatycznie dostępu do usługi Azure Pipelines. Usługa Azure Pipelines nie zna tożsamości usługi GitHub. Z tego powodu nie ma możliwości skonfigurowania usługi Azure Pipelines w celu automatycznego powiadamiania użytkowników o niepowodzeniu kompilacji lub niepowodzeniu weryfikacji żądania ściągnięcia przy użyciu tożsamości i adresu e-mail usługi GitHub. Aby replikować użytkowników usługi GitHub, musisz jawnie utworzyć nowych użytkowników w usłudze Azure Pipelines. Po utworzeniu nowych użytkowników możesz skonfigurować ich uprawnienia w usłudze Azure DevOps w celu odzwierciedlenia ich uprawnień w usłudze GitHub. Powiadomienia w usłudze DevOps można również skonfigurować przy użyciu tożsamości metodyki DevOps.

Role organizacji usługi GitHub

Role członków organizacji w usłudze GitHub znajdują się w lokalizacji https://github.com/orgs/your-organization/people (zastąp your-organizationelement ).

Uprawnienia członków organizacji devOps znajdują się w lokalizacji https://dev.azure.com/your-organization/_settings/security (zastąp your-organizationelement ).

Poniżej przedstawiono role w organizacji usługi GitHub i równoważne role w organizacji usługi Azure DevOps.

Rola organizacji usługi GitHub Odpowiednik organizacji DevOps
Właściciel Członek Project Collection Administrators
Billing manager (Menedżer rozliczeń) Członek Project Collection Administrators
Element członkowski Element członkowski .Project Collection Valid Users Domyślnie grupa Członek nie ma uprawnień do tworzenia nowych projektów. Aby zmienić uprawnienie, ustaw uprawnienie grupy Create new projects na Allow, lub utwórz nową grupę z potrzebnymi uprawnieniami.

Role konta użytkownika usługi GitHub

Konto użytkownika usługi GitHub ma jedną rolę, która jest własnością konta.

Uprawnienia członków organizacji devOps znajdują się w lokalizacji https://dev.azure.com/your-organization/_settings/security (zastąp your-organizationelement ).

Rola konta użytkownika usługi GitHub mapuje się na uprawnienia organizacji devOps w następujący sposób.

Rola konta użytkownika usługi GitHub Odpowiednik organizacji DevOps
Właściciel Członek Project Collection Administrators

Uprawnienia repozytorium GitHub

Uprawnienia repozytorium GitHub można znaleźć na stronie https://github.com/your-organization/your-repository/settings/collaboration (zastąp your-organization i your-repository).

Uprawnienia projektu DevOps znajdują się pod adresem https://dev.azure.com/your-organization/your-project/_settings/security (zastąp your-organization i your-project).

Równoważne uprawnienia między repozytoriami GitHub i usługą Azure DevOps Projects są następujące.

Uprawnienie do repozytorium GitHub Odpowiednik projektu DevOps
Administrator Członek Project Administrators
Write Członek Contributors
Przeczytaj Członek Readers

Jeśli repozytorium GitHub udziela uprawnień zespołom, możesz utworzyć pasujące zespoły w Teams sekcji ustawień projektu usługi Azure DevOps. Następnie dodaj zespoły do powyższych grup zabezpieczeń, podobnie jak użytkownicy.

Uprawnienia specyficzne dla potoku

Aby przyznać użytkownikom lub zespołom uprawnienia do określonych potoków w projekcie DevOps, wykonaj następujące kroki:

  1. Odwiedź stronę Potoki projektu (na przykład https://dev.azure.com/your-organization/your-project/_build).
  2. Wybierz potok, dla którego chcesz ustawić określone uprawnienia.
  3. Z menu kontekstowego "..." wybierz pozycję Zabezpieczenia.
  4. Wybierz pozycję Dodaj... , aby dodać określonego użytkownika, zespołu lub grupy i dostosować swoje uprawnienia dla potoku.

Dostęp do repozytoriów GitHub

Utwórz nowy potok, wybierając najpierw repozytorium GitHub, 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.

Usługa Azure Pipelines musi mieć dostęp do repozytoriów w celu wyzwolenia kompilacji i pobrania kodu podczas kompilacji.

Istnieją trzy typy uwierzytelniania służące do udzielania usłudze Azure Pipelines dostępu do repozytoriów GitHub podczas tworzenia potoku.

Typ uwierzytelniania Potoki są uruchamiane przy użyciu polecenia Działa z funkcjami sprawdzania w usłudze GitHub
1. Aplikacja GitHub Tożsamość usługi Azure Pipelines Tak
2. Uwierzytelnianie OAuth Twoja osobista tożsamość usługi GitHub Nie.
3. Osobisty token dostępu (PAT) Twoja osobista tożsamość usługi GitHub Nie.

Uwierzytelnianie aplikacji w usłudze GitHub

Aplikacja GitHub usługi Azure Pipelines jest zalecanym typem uwierzytelniania dla potoków ciągłej integracji. Po zainstalowaniu aplikacji GitHub na koncie lub organizacji usługi GitHub potok zostanie uruchomiony bez użycia osobistej tożsamości usługi GitHub. Kompilacje i aktualizacje stanu usługi GitHub będą wykonywane przy użyciu tożsamości usługi Azure Pipelines. Aplikacja współpracuje z usługą GitHub Checks w celu wyświetlenia wyników kompilacji, testowania i pokrycia kodu w usłudze GitHub.

Aby użyć aplikacji GitHub, zainstaluj ją w organizacji usługi GitHub lub na koncie użytkownika dla niektórych lub wszystkich repozytoriów. Aplikację GitHub można zainstalować i odinstalować ze strony głównej aplikacji.

Po zakończeniu instalacji aplikacja GitHub stanie się domyślną metodą uwierzytelniania usługi Azure Pipelines w usłudze GitHub (zamiast OAuth), gdy potoki są tworzone dla repozytoriów.

Jeśli zainstalujesz aplikację GitHub dla wszystkich repozytoriów w organizacji usługi GitHub, nie musisz martwić się o wysyłanie masowych wiadomości e-mail ani automatyczne konfigurowanie potoków w Twoim imieniu. Zamiast instalowania aplikacji dla wszystkich repozytoriów administratorzy repozytoriów mogą zainstalować ją pojedynczo dla poszczególnych repozytoriów. Wymaga to większej ilości pracy dla administratorów, ale nie ma korzyści ani wad.

Wymagane uprawnienia w usłudze GitHub

Instalacja aplikacji GitHub usługi Azure Pipelines wymaga, aby być właścicielem lub administratorem repozytorium w usłudze GitHub. Ponadto aby utworzyć potok dla repozytorium GitHub z wyzwalaczami ciągłej integracji i żądań ściągnięcia, musisz mieć skonfigurowane wymagane uprawnienia usługi GitHub. W przeciwnym razie repozytorium nie będzie wyświetlane na liście repozytoriów podczas tworzenia potoku. W zależności od typu uwierzytelniania i własności repozytorium upewnij się, że skonfigurowano odpowiedni dostęp.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub, zainstaluj aplikację GitHub usługi Azure Pipelines na osobistym koncie usługi GitHub i będzie można wyświetlić listę tego repozytorium podczas tworzenia potoku w usłudze Azure Pipelines.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub innej osoby, inna osoba musi zainstalować aplikację GitHub usługi Azure Pipelines na osobistym koncie usługi GitHub. Musisz dodać cię jako współpracownika w ustawieniach repozytorium w obszarze "Współpracownicy". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail. Po wykonaniu tych czynności możesz utworzyć potok dla tego repozytorium.

  • Jeśli repozytorium znajduje się we własnej organizacji usługi GitHub, zainstaluj aplikację GitHub usługi Azure Pipelines w organizacji usługi GitHub. Musisz również dodać cię jako współpracownika lub należy dodać swój zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły".

  • Jeśli repozytorium znajduje się w organizacji usługi GitHub, która jest właścicielem innej osoby, właściciel organizacji lub administrator repozytorium usługi GitHub w usłudze GitHub musi zainstalować aplikację GitHub usługi Azure Pipelines w organizacji. Musisz dodać Cię jako współpracownika lub należy dodać zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail.

Uprawnienia aplikacji GitHub

Aplikacja GitHub żąda następujących uprawnień podczas instalacji:

Uprawnienie Jak usługa Azure Pipelines używa uprawnienia
Pisanie dostępu do kodu Tylko po celowym działaniu usługa Azure Pipelines uprości tworzenie potoku, zatwierdzając plik YAML w wybranej gałęzi repozytorium GitHub.
Dostęp do odczytu do metadanych Usługa Azure Pipelines pobierze metadane usługi GitHub na potrzeby wyświetlania repozytorium, gałęzi i problemów skojarzonych z kompilacją w podsumowaniu kompilacji.
Dostęp do odczytu i zapisu w celu sprawdzenia Usługa Azure Pipelines odczytuje i zapisuje własne wyniki kompilacji, testowania i pokrycia kodu, które będą wyświetlane w usłudze GitHub.
Dostęp do odczytu i zapisu do żądań ściągnięcia Tylko po celowej akcji usługa Azure Pipelines uprości tworzenie potoku, tworząc żądanie ściągnięcia dla pliku YAML zatwierdzonego w wybranej gałęzi repozytorium GitHub. Potoki pobiera metadane żądania do wyświetlenia w podsumowaniach kompilacji skojarzonych z żądaniami ściągnięcia.

Rozwiązywanie problemów z instalacją aplikacji GitHub

Usługa GitHub może wyświetlać błąd, taki jak:

You do not have permission to modify this app on your-organization. Please contact an Organization Owner.

Oznacza to, że aplikacja GitHub prawdopodobnie jest już zainstalowana dla Twojej organizacji. Po utworzeniu potoku dla repozytorium w organizacji aplikacja GitHub zostanie automatycznie użyta do nawiązania połączenia z usługą GitHub.

Tworzenie potoków w wielu organizacjach i projektach usługi Azure DevOps

Po zainstalowaniu aplikacji GitHub potoki można tworzyć dla repozytoriów organizacji w różnych organizacjach i projektach usługi Azure DevOps. Jednak jeśli tworzysz potoki dla pojedynczego repozytorium w wielu organizacjach usługi Azure DevOps, tylko potoki pierwszej organizacji mogą być automatycznie wyzwalane przez zatwierdzenia lub żądania ściągnięcia usługi GitHub. Kompilacje ręczne lub zaplanowane są nadal możliwe w dodatkowych organizacjach usługi Azure DevOps.

Uwierzytelnianie OAuth

Uwierzytelnianie OAuth to najprostszy typ uwierzytelniania, który umożliwia rozpoczęcie pracy z repozytoriami na osobistym koncie usługi GitHub. Aktualizacje stanu usługi GitHub będą wykonywane w imieniu osobistej tożsamości usługi GitHub. Aby potoki działały, dostęp do repozytorium musi pozostać aktywny. Niektóre funkcje usługi GitHub, takie jak Testy, są niedostępne z uwierzytelnianiem OAuth i wymagają aplikacji GitHub.

Aby użyć protokołu OAuth, wybierz pozycję Wybierz inne połączenie poniżej listy repozytoriów podczas tworzenia potoku. Następnie wybierz pozycję Autoryzuj , aby zalogować się do usługi GitHub i autoryzować przy użyciu protokołu OAuth. Połączenie OAuth zostanie zapisane w projekcie usługi Azure DevOps do późniejszego użycia i użyte w tworzonym potoku.

Wymagane uprawnienia w usłudze GitHub

Aby utworzyć potok dla repozytorium GitHub z wyzwalaczami ciągłej integracji i żądania ściągnięcia, musisz mieć skonfigurowane wymagane uprawnienia usługi GitHub. W przeciwnym razie repozytorium nie będzie wyświetlane na liście repozytoriów podczas tworzenia potoku. W zależności od typu uwierzytelniania i własności repozytorium upewnij się, że skonfigurowano odpowiedni dostęp.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub, co najmniej raz uwierzytelnij się w usłudze GitHub przy użyciu protokołu OAuth przy użyciu osobistych poświadczeń konta usługi GitHub. Można to zrobić w ustawieniach projektu usługi Azure DevOps w obszarze Połączenia usługi Pipelines > Service Nowa połączenie > usługi GitHub > Autoryzowanie.> Udziel usłudze Azure Pipelines dostępu do repozytoriów w obszarze "Uprawnienia" tutaj.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub innej osoby, co najmniej raz inna osoba musi uwierzytelnić się w usłudze GitHub przy użyciu protokołu OAuth przy użyciu osobistych poświadczeń konta usługi GitHub. Można to zrobić w ustawieniach projektu usługi Azure DevOps w obszarze Połączenia usługi Pipelines > Service Nowa połączenie > usługi GitHub > Autoryzowanie.> Druga osoba musi udzielić usłudze Azure Pipelines dostępu do swoich repozytoriów w obszarze "Uprawnienia" tutaj. Musisz dodać cię jako współpracownika w ustawieniach repozytorium w obszarze "Współpracownicy". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail.

  • Jeśli repozytorium znajduje się w organizacji usługi GitHub, której jesteś właścicielem, co najmniej raz, uwierzytelnij się w usłudze GitHub przy użyciu protokołu OAuth przy użyciu osobistych poświadczeń konta usługi GitHub. Można to zrobić w ustawieniach projektu usługi Azure DevOps w obszarze Połączenia usługi Pipelines > Service Nowa połączenie > usługi GitHub > Autoryzowanie.> Udziel usłudze Azure Pipelines dostępu do organizacji w obszarze "Dostęp do organizacji" tutaj. Musisz dodać Cię jako współpracownika lub należy dodać zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły".

  • Jeśli repozytorium znajduje się w organizacji usługi GitHub, która jest właścicielem innej osoby, co najmniej raz, właściciel organizacji usługi GitHub musi uwierzytelnić się w usłudze GitHub przy użyciu protokołu OAuth przy użyciu osobistych poświadczeń konta usługi GitHub. Można to zrobić w ustawieniach projektu usługi Azure DevOps w obszarze Połączenia usługi Pipelines > Service Nowa połączenie > usługi GitHub > Autoryzowanie.> Właściciel organizacji musi udzielić organizacji dostępu do usługi Azure Pipelines w obszarze "Dostęp do organizacji" tutaj. Musisz dodać Cię jako współpracownika lub należy dodać zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail.

Odwoływanie dostępu OAuth

Po autoryzowaniu usługi Azure Pipelines do używania protokołu OAuth w celu późniejszego odwołania go i uniemożliwienia dalszego użycia odwiedź stronę OAuth Apps w ustawieniach usługi GitHub. Możesz również usunąć je z listy połączeń usługi GitHub w ustawieniach projektu usługi Azure DevOps.

Uwierzytelnianie osobistego tokenu dostępu (PAT)

Dostawcy paTs są w rzeczywistości takie same jak protokół OAuth, ale umożliwiają kontrolowanie, które uprawnienia są przyznawane usłudze Azure Pipelines. Kompilacje i aktualizacje stanu usługi GitHub będą wykonywane w imieniu osobistej tożsamości usługi GitHub. Aby kompilacje nadal działały, dostęp do repozytorium musi pozostać aktywny.

Aby utworzyć osobisty token dostępu, odwiedź stronę Osobiste tokeny dostępu w ustawieniach usługi GitHub. Wymagane uprawnienia to repo, , admin:repo_hookread:useri user:email. Są to te same uprawnienia wymagane w przypadku używania protokołu OAuth powyżej. Skopiuj wygenerowany identyfikator PAT do schowka i wklej go do nowego połączenia usługi GitHub w ustawieniach projektu usługi Azure DevOps. W przyszłości nazwij połączenie z usługą po nazwie użytkownika usługi GitHub. Będzie ona dostępna w projekcie usługi Azure DevOps do późniejszego użycia podczas tworzenia potoków.

Wymagane uprawnienia w usłudze GitHub

Aby utworzyć potok dla repozytorium GitHub z wyzwalaczami ciągłej integracji i żądania ściągnięcia, musisz mieć skonfigurowane wymagane uprawnienia usługi GitHub. W przeciwnym razie repozytorium nie będzie wyświetlane na liście repozytoriów podczas tworzenia potoku. W zależności od typu uwierzytelniania i własności repozytorium upewnij się, że skonfigurowano następujący dostęp.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub, identyfikator PAT musi mieć wymagane zakresy dostępu w obszarze Osobiste tokeny dostępu: repo, , admin:repo_hookread:useri user:email.

  • Jeśli repozytorium znajduje się na osobistym koncie usługi GitHub innej osoby, identyfikator PAT musi mieć wymagane zakresy dostępu w obszarze Osobiste tokeny dostępu: repo, , admin:repo_hookread:useri user:email. Musisz dodać cię jako współpracownika w ustawieniach repozytorium w obszarze "Współpracownicy". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail.

  • Jeśli repozytorium znajduje się w organizacji usługi GitHub, której jesteś właścicielem, identyfikator pat musi mieć wymagane zakresy dostępu w obszarze Osobiste tokeny dostępu: repo, , admin:repo_hookread:useri user:email. Musisz dodać Cię jako współpracownika lub należy dodać zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły".

  • Jeśli repozytorium znajduje się w organizacji usługi GitHub, która jest właścicielem innej osoby, identyfikator PAT musi mieć wymagane zakresy dostępu w obszarze Osobiste tokeny dostępu: repo, , admin:repo_hookread:useri user:email. Musisz dodać Cię jako współpracownika lub należy dodać zespół w ustawieniach repozytorium w obszarze "Współpracownicy i zespoły". Zaakceptuj zaproszenie, aby być współpracownikiem, korzystając z linku, który jest do Ciebie e-mail.

Odwoływanie dostępu pat

Po autoryzowaniu usługi Azure Pipelines do korzystania z tokenu PAT, aby później go usunąć i uniemożliwić dalsze użycie, odwiedź stronę Osobiste tokeny dostępu w ustawieniach usługi GitHub. Możesz również usunąć je z listy połączeń usługi GitHub w ustawieniach projektu usługi Azure DevOps.

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.

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.

Pomijanie ciągłej integracji dla poszczególnych zatwierdzeń

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 za każdym razem, gdy żądanie ściągnięcia zostanie otwarte z jedną z określonych gałęzi docelowych lub gdy aktualizacje zostaną wprowadzone do takiego żądania ściągnięcia.

Odgałęzienia

Gałęzie docelowe można określić podczas sprawdzania poprawności żądań ściągnięcia. Na przykład, aby zweryfikować żądania ściągnięcia, które są docelowe main i releases/*, można użyć następującego pr wyzwalacza.

pr:
- main
- releases/*

Ta konfiguracja uruchamia nowy przebieg przy pierwszym utworzeniu nowego żądania ściągnięcia i po każdej aktualizacji żądania ściągnięcia.

Możesz określić pełną nazwę gałęzi (na przykład main) lub symbol wieloznaczny (na przykład releases/*).

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.

Usługa GitHub tworzy nowy element ref podczas tworzenia żądania ściągnięcia. Odwołanie wskazuje zatwierdzenie scalania, które jest scalanym kodem między gałęziami źródłowymi i docelowymi żądania ściągnięcia. Potok weryfikacji żądania ściągnięcia tworzy zatwierdzenie, do którego to odwołanie wskazuje. Oznacza to, że plik YAML używany do uruchamiania potoku jest również scalania między źródłem a gałęzią docelową. W związku z tym zmiany wprowadzone w pliku YAML w gałęzi źródłowej żądania ściągnięcia mogą zastąpić zachowanie zdefiniowane przez plik YAML w gałęzi docelowej.

Jeśli w pliku YAML nie są wyświetlane żadne pr wyzwalacze, walidacje żądań ściągnięcia są automatycznie włączone dla wszystkich gałęzi, tak jak w przypadku napisano następujący pr wyzwalacz. Ta konfiguracja wyzwala kompilację po utworzeniu dowolnego żądania ściągnięcia, a gdy zatwierdzenia wchodzą do gałęzi źródłowej dowolnego aktywnego żądania ściągnięcia.

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

Ważne

Po określeniu pr wyzwalacza z podzbiorem gałęzi potok jest wyzwalany tylko wtedy, gdy aktualizacje są wypychane do tych gałęzi.

W przypadku bardziej złożonych wyzwalaczy, które muszą wykluczać niektóre gałęzie, należy użyć pełnej składni, jak pokazano w poniższym przykładzie. W tym przykładzie żądania ściągnięcia są weryfikowane, czy element docelowy main lub releases/* gałąź releases/old* jest wykluczona.

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

Ścieżki

Można określić ścieżki plików do uwzględnienia lub wykluczenia. Na przykład:

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

Porady:

  • Usługa Azure Pipelines publikuje neutralny stan z powrotem do usługi GitHub, gdy zdecyduje się nie uruchomić kompilacji weryfikacji z powodu reguły wykluczania ścieżki. Zapewnia to jasny kierunek dla usługi GitHub wskazujący, że usługa Azure Pipelines zakończyła przetwarzanie. Aby uzyskać więcej informacji, zobacz Post neutral status to GitHub when a build is skipped (Publikowanie stanu neutralnego w usłudze GitHub po pomijaniu kompilacji).
  • Symbole wieloznaczne są teraz obsługiwane z filtrami ś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).
  • Usługa Azure Pipelines publikuje neutralny stan z powrotem do usługi GitHub, gdy zdecyduje się nie uruchomić kompilacji weryfikacji z powodu reguły wykluczania ścieżki.

Wiele aktualizacji żądania ściągnięcia

Można określić, czy więcej aktualizacji żądania ściągnięcia powinno anulować przebiegi walidacji w toku dla tego samego żądania ściągnięcia. Wartość domyślna to true.

# auto cancel false
pr:
  autoCancel: false
  branches:
    include:
    - main

Weryfikacja wersji roboczej żądania ściągnięcia

Domyślnie wyzwalacze żądań ściągnięcia są uruchamiane na żądaniach ściągnięcia i żądaniach ściągnięcia gotowych do przeglądu. Aby wyłączyć wyzwalacze żądań ściągnięcia dla żądań ściągnięcia w wersji roboczej, ustaw drafts właściwość na falsewartość .

pr:
  autoCancel: boolean # indicates whether additional pushes to a PR should cancel in-progress runs for the same PR. Defaults to true
  branches:
    include: [ string ] # branch names which will trigger a build
    exclude: [ string ] # branch names which will not
  paths:
    include: [ string ] # file paths which must match to trigger a build
    exclude: [ string ] # file paths which will not trigger a build
  drafts: boolean # whether to build draft PRs, defaults to true

Rezygnacja z weryfikacji żądania ściągnięcia

Możesz całkowicie zrezygnować z weryfikacji żądania ściągnięcia, określając .pr: none

# no PR triggers
pr: none

Aby uzyskać więcej informacji, zobacz Wyzwalacz żądania ściągnięcia w schemacie YAML.

Uwaga

pr Jeśli wyzwalacz nie jest wyzwalany, wykonaj kroki rozwiązywania problemów z często zadawanymi pytaniami.

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, które mają wyzwalacz żądania ściągnięcia w gałęzi docelowej żądania ściągnięcia, 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, jeśli komunikat lub opis zatwierdzenia scalania nie zawiera [skip ci] (ani żadnego z jego wariantów).

Chronione gałęzie

Możesz uruchomić kompilację weryfikacji z każdym zatwierdzeniem lub żądaniem ściągnięcia, które jest przeznaczone dla gałęzi, a nawet uniemożliwić scalanie żądań ściągnięcia, dopóki kompilacja weryfikacji nie powiedzie się.

Aby skonfigurować obowiązkowe kompilacje weryfikacji dla repozytorium GitHub, musisz być jego właścicielem, współpracownikiem z rolą administratora lub członkiem organizacji usługi GitHub z rolą Zapis.

  1. Najpierw utwórz potok dla repozytorium i skompiluj go co najmniej raz, aby jego stan został opublikowany w usłudze GitHub, dzięki czemu usługa GitHub rozpoznała nazwę potoku.

  2. Następnie postępuj zgodnie z dokumentacją usługi GitHub, aby skonfigurować chronione gałęzie w ustawieniach repozytorium.

    Aby sprawdzić stan, wybierz nazwę potoku na liście Sprawdzanie stanu.

    Sprawdzanie stanu potoku usługi GitHub

Ważne

Jeśli potok nie jest wyświetlany na tej liście, upewnij się, że:

Współtworzenie ze źródeł zewnętrznych

Jeśli repozytorium GitHub jest repozytorium typu open source, możesz udostępnić publiczny projekt usługi Azure DevOps, aby każdy mógł wyświetlać wyniki kompilacji, dzienniki i wyniki testów potoku bez logowania. Gdy użytkownicy spoza organizacji rozwidli repozytorium i przesyłają żądania ściągnięcia, mogą wyświetlać stan kompilacji, które automatycznie weryfikują te żądania ściągnięcia.

Podczas korzystania z usługi Azure Pipelines w projekcie publicznym podczas akceptowania współtworzenia ze źródeł zewnętrznych należy pamiętać o następujących kwestiach.

Ograniczenia dostępu

Podczas uruchamiania potoków w projektach publicznych usługi Azure DevOps należy pamiętać o następujących ograniczeniach dostępu:

  • Wpisy tajne: domyślnie wpisy tajne skojarzone z potokiem nie są udostępniane do weryfikacji żądań ściągnięcia rozwidlenia. Zobacz Weryfikowanie współtworzenia z rozwidlenia.
  • Dostęp między projektami: wszystkie potoki w publicznym projekcie usługi Azure DevOps są uruchamiane z tokenem dostępu ograniczonym do projektu. Potoki w projekcie publicznym mogą uzyskiwać dostęp do zasobów, takich jak artefakty kompilacji lub wyniki testów tylko w projekcie, a nie w innych projektach organizacji usługi Azure DevOps.
  • Pakiety usługi Azure Artifacts: jeśli potoki potrzebują dostępu do pakietów z usługi Azure Artifacts, musisz jawnie udzielić uprawnień do konta usługi Project Build Service w celu uzyskania dostępu do kanałów informacyjnych pakietów.

Współtworzenie rozwidlenia

Ważne

Te ustawienia wpływają na bezpieczeństwo potoku.

Po utworzeniu potoku jest on automatycznie wyzwalany dla żądań ściągnięcia z rozwidlenia repozytorium. Możesz zmienić to zachowanie, uważnie biorąc pod uwagę, jak wpływa na bezpieczeństwo. Aby włączyć lub wyłączyć to zachowanie:

  1. Przejdź do projektu usługi Azure DevOps. Wybierz pozycję Potoki, znajdź potok, a następnie wybierz pozycję Edytuj.
  2. Wybierz kartę Wyzwalacze. Po włączeniu wyzwalacza żądania ściągnięcia włącz lub wyłącz pole wyboru Kompiluj żądania ściągnięcia z rozwidlenia tego repozytorium.

Domyślnie w przypadku potoków usługi GitHub wpisy tajne skojarzone z potokiem kompilacji nie są udostępniane kompilacjom rozwidlenia żądań ściągnięcia. Te wpisy tajne są domyślnie włączone przy użyciu potoków serwera GitHub Enterprise Server. Wpisy tajne obejmują:

Aby obejść ten środek ostrożności w potokach usługi GitHub, włącz pole wyboru Udostępnij wpisy tajne dla kompilacji rozwidleń . Należy pamiętać o wpływie tego ustawienia na zabezpieczenia.

Uwaga

Po włączeniu kompilacji rozwidlenia w celu uzyskania dostępu do wpisów tajnych usługa Azure Pipelines domyślnie ogranicza token dostępu używany w przypadku kompilacji rozwidlenia. Ma on bardziej ograniczony dostęp do otwartych zasobów niż normalny token dostępu. Aby nadać rozwidlenie kompiluje te same uprawnienia co zwykłe kompilacje, włącz opcję Utwórz kompilacje rozwidlenia mają takie same uprawnienia jak zwykłe ustawienia kompilacji .

Aby uzyskać więcej informacji, zobacz Ochrona repozytorium — rozwidlenia.

Możesz zdefiniować centralnie sposób tworzenia żądań ściągnięcia potoków z rozwidlonych repozytoriów GitHub przy użyciu kontrolki Ogranicz żądania ściągnięcia kompilacji z rozwidlenia repozytoriów GitHub. Jest ona dostępna na poziomie organizacji i projektu. Można wybrać opcję:

  • Wyłączanie tworzenia żądań ściągnięcia z rozwidlonych repozytoriów
  • Bezpieczne tworzenie żądań ściągnięcia z rozwidlonych repozytoriów
  • Dostosowywanie reguł tworzenia żądań ściągnięcia z rozwidlonych repozytoriów

Zrzut ekranu przedstawiający scentralizowane ustawienia kontroli dotyczące sposobu tworzenia żądania ściągnięcia potoków z rozwidlonych repozytoriów GitHub.

Począwszy od przebiegu 229, aby zwiększyć bezpieczeństwo potoków, usługa Azure Pipelines nie tworzy już automatycznie żądań ściągnięcia z rozwidlonych repozytoriów GitHub. W przypadku nowych projektów i organizacji wartość domyślna ustawienia Ogranicz żądania ściągnięcia kompilacji z rozwidlenia repozytoriów GitHub to Wyłącz tworzenie żądań ściągnięcia z rozwidlonych repozytoriów.

W przypadku wybrania opcji Bezpieczne kompilowanie żądań ściągnięcia z rozwidlonych repozytoriów wszystkie potoki, organizacja lub cały projekt nie mogą udostępniać wpisów tajnych kompilacjom z rozwidlonych repozytoriów, nie mogą one mieć takich samych uprawnień jak zwykłe kompilacje i muszą zostać wyzwolone przez komentarz żądania ściągnięcia. Projekty nadal mogą nie zezwalać potokom na tworzenie takich żądania ściągnięcia.

Po wybraniu opcji Dostosuj można zdefiniować sposób ograniczania ustawień potoku. Możesz na przykład upewnić się, że wszystkie potoki wymagają komentarza w celu utworzenia żądania ściągnięcia z rozwidlenia repozytorium GitHub, gdy żądanie ściągnięcia należy do członków innych niż zespoły i współautorów innych niż współautorzy. Można jednak zezwolić im na udostępnianie wpisów tajnych takim kompilacjom. Projekty mogą nie zezwalać potokom na tworzenie takich żądania ściągnięcia lub tworzenie ich w bezpieczny sposób lub mieć jeszcze bardziej restrykcyjne ustawienia niż określone na poziomie organizacji.

Kontrolka jest wyłączona dla istniejących organizacji. Od września 2023 r. nowe organizacje mają domyślnie włączone bezpieczne tworzenie żądań ściągnięcia z rozwidlonych repozytoriów.

Ważne zagadnienia dotyczące zabezpieczeń

Użytkownik usługi GitHub może rozwidlić repozytorium, zmienić je i utworzyć żądanie ściągnięcia, aby zaproponować zmiany w repozytorium. To żądanie ściągnięcia może zawierać złośliwy kod do uruchomienia w ramach wyzwolonej kompilacji. Taki kod może spowodować szkodę w następujący sposób:

  • Wyciek wpisów tajnych z potoku. Aby ograniczyć to ryzyko, nie włączaj pola wyboru Udostępnij wpisy tajne dla kompilacji rozwidlenia , jeśli repozytorium jest publiczne lub niezaufane użytkownicy mogą przesyłać żądania ściągnięcia, które automatycznie wyzwalają kompilacje. Ta opcja jest domyślnie wyłączona.

  • Naruszenie zabezpieczeń maszyny uruchamianej przez agenta w celu kradzieży kodu lub wpisów tajnych z innych potoków. Aby rozwiązać ten problem:

    • Użyj puli agentów hostowanych przez firmę Microsoft do tworzenia żądań ściągnięcia z rozwidlenia. Maszyny agentów hostowane przez firmę Microsoft są natychmiast usuwane po zakończeniu kompilacji, więc nie ma trwałego wpływu, jeśli zostaną naruszone.

    • Jeśli musisz użyć własnego agenta, nie przechowuj żadnych wpisów tajnych ani nie wykonuj innych kompilacji i wydań korzystających z wpisów tajnych na tym samym agencie, chyba że repozytorium jest prywatne i ufasz twórcom żądań ściągnięcia.

Wyzwalacze komentarza

Współpracownicy repozytorium mogą komentować żądanie ściągnięcia, aby ręcznie uruchomić potok. Oto kilka typowych powodów, dla których warto to zrobić:

  • Możesz nie chcieć automatycznie kompilować żądań ściągnięcia od nieznanych użytkowników do czasu przejrzenia ich zmian. Chcesz, aby jeden z członków zespołu najpierw przejrzeł swój kod, a następnie uruchomić potok. Jest to często używane jako środek zabezpieczeń podczas kompilowania kodu współautora z rozwidlonych repozytoriów.
  • Możesz chcieć uruchomić opcjonalny zestaw testów lub jedną kompilację weryfikacji.

Aby włączyć wyzwalacze komentarza, należy wykonać następujące dwa kroki:

  1. Włącz wyzwalacze żądania ściągnięcia dla potoku i upewnij się, że nie wykluczyno gałęzi docelowej.
  2. W portalu internetowym usługi Azure Pipelines zmodyfikuj potok i wybierz pozycję Więcej akcji Wyzwalacze. Następnie w obszarze Walidacja żądania ściągnięcia włącz opcję Wymagaj komentarza członka zespołu przed utworzeniem żądania ściągnięcia.
    • Wybierz pozycję We wszystkich żądaniach ściągnięcia, aby wymagać komentarza członka zespołu przed utworzeniem żądania ściągnięcia. Dzięki temu przepływowi pracy członek zespołu przegląda żądanie ściągnięcia i wyzwala kompilację z komentarzem po uznaniu żądania ściągnięcia za bezpieczne.
    • Wybierz pozycję Tylko w przypadku żądań ściągnięcia od członków nienależących do zespołu, aby wymagać komentarza członka zespołu tylko wtedy, gdy żądanie ściągnięcia zostanie wykonane przez członka nienależącego do zespołu. W tym przepływie pracy członek zespołu nie potrzebuje przeglądu członka zespołu pomocniczego, aby wyzwolić kompilację.

W przypadku tych dwóch zmian kompilacja weryfikacji żądania ściągnięcia nie zostanie wyzwolona automatycznie, chyba że wybrano opcję Tylko na żądania ściągnięcia od członków innych niż członkowie zespołu i żądanie ściągnięcia zostanie dokonane przez członka zespołu. Tylko właściciele repozytoriów i współpracownicy z uprawnieniem "Zapis" mogą wyzwolić kompilację, komentując żądanie ściągnięcia za pomocą /AzurePipelines run polecenia lub /AzurePipelines run <pipeline-name>.

Następujące polecenia można wydać do usługi Azure Pipelines w komentarzach:

Polecenie Result
/AzurePipelines help Wyświetl pomoc dotyczącą wszystkich obsługiwanych poleceń.
/AzurePipelines help <command-name> Wyświetl pomoc dla określonego polecenia.
/AzurePipelines run Uruchom wszystkie potoki skojarzone z tym repozytorium i których wyzwalacze nie wykluczają tego żądania ściągnięcia.
/AzurePipelines run <pipeline-name> Uruchom określony potok, chyba że jego wyzwalacze wykluczają to żądanie ściągnięcia.

Uwaga

W przypadku zwięzłości możesz komentować zamiast /azp /AzurePipelines.

Ważne

Odpowiedzi na te polecenia będą wyświetlane w dyskusji dotyczącej żądania ściągnięcia tylko wtedy, gdy potok używa aplikacji GitHub usługi Azure Pipelines.

Rozwiązywanie problemów z wyzwalaczami komentarza żądania ściągnięcia

Jeśli masz niezbędne uprawnienia do repozytorium, ale potoki nie są wyzwalane przez komentarze, upewnij się, że członkostwo jest publiczne w organizacji repozytorium lub bezpośrednio dodaj siebie jako współpracownika repozytorium. Potoki nie widzą członków prywatnej organizacji, chyba że są bezpośrednimi współpracownikami lub należą do zespołu, który jest bezpośrednim współpracownikiem. Możesz zmienić członkostwo organizacji w usłudze GitHub z prywatnej na publiczną tutaj (zastąp Your-Organization ciąg nazwą swojej organizacji): https://github.com/orgs/Your-Organization/people.

Uruchomienia informacyjne

Uruchomienie informacyjne informuje, że usługa Azure DevOps nie może pobrać kodu źródłowego potoku YAML. Pobieranie kodu źródłowego odbywa się w odpowiedzi na zdarzenia zewnętrzne, na przykład wypychane zatwierdzenie. Dzieje się to również w odpowiedzi na wyzwalacze wewnętrzne, na przykład, aby sprawdzić, czy istnieją zmiany kodu i rozpocząć zaplanowane uruchomienie, czy nie. Pobieranie kodu źródłowego może zakończyć się niepowodzeniem z wielu powodów, z częstym ograniczaniem żądań przez dostawcę repozytorium git. Istnienie przebiegu informacyjnego niekoniecznie oznacza, że usługa Azure DevOps będzie uruchamiać potok.

Przebieg informacyjny wygląda podobnie jak na poniższym zrzucie ekranu.

Zrzut ekranu przedstawiający uruchamianie potoku informacyjnego.

Przebieg informacyjny można rozpoznać za pomocą następujących atrybutów:

  • Stan to Canceled
  • Czas trwania to < 1s
  • Nazwa przebiegu zawiera jeden z następujących tekstów:
    • Could not retrieve file content for {file_path} from repository {repo_name} hosted on {host} using commit {commit_sha}.
    • Could not retrieve content for object {commit_sha} from repository {repo_name} hosted on {host}.
    • Could not retrieve the tree object {tree_sha} from the repository {repo_name} hosted on {host}.
    • Could not find {file_path} from repository {repo_name} hosted on {host} using version {commit_sha}. One of the directories in the path contains too many files or subdirectories.
  • Nazwa uruchomienia zazwyczaj zawiera błąd BitBucket/GitHub, który spowodował niepowodzenie ładowania potoku YAML
  • Brak etapów/zadań/kroków

Dowiedz się więcej na temat przebiegów informacyjnych.

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

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

Podmoduły

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

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.

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.

    Zrzut ekranu przedstawiający menu więcej wyzwalaczy.

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

    Zrzut ekranu przedstawiający pobieranie źródeł.

  3. Skonfiguruj ustawienie Synchronizuj tagi.

    Zrzut ekranu przedstawiający ustawienie Synchronizacja tagów.

Uwaga

Jeśli jawnie ustawisz fetchTags w checkout kroku, to ustawienie ma priorytet nad ustawieniem skonfigurowanym w interfejsie użytkownika ustawień 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.

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.

    Zrzut ekranu przedstawiający menu więcej wyzwalaczy.

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

    Zrzut ekranu przedstawiający pobieranie źródeł.

  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.

    Zrzut ekranu przedstawiający opcje.

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 .

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.

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

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

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.

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.

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

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.

Skonfiguruj opcje usługi Git, YAML.

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

W edytorze klasycznym wybierz pozycję YAML > Pobierz źródła.

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.

Wstępnie zdefiniowane zmienne

Podczas tworzenia repozytorium GitHub większość wstępnie zdefiniowanych zmiennych jest dostępna dla zadań. Jednak ponieważ usługa Azure Pipelines nie rozpoznaje tożsamości użytkownika tworzącego aktualizację w usłudze GitHub, następujące zmienne są ustawione na tożsamość systemową zamiast tożsamości użytkownika:

  • Build.RequestedFor
  • Build.RequestedForId
  • Build.RequestedForEmail

Aktualizacje stanu

Istnieją dwa typy stanów, które usługa Azure Pipelines publikuje z powrotem w usłudze GitHub — podstawowe stany i uruchomienia sprawdzania w usłudze GitHub. Funkcja Sprawdzania usługi GitHub jest dostępna tylko w przypadku aplikacji GitHub.

Stany potoków są wyświetlane w różnych miejscach w interfejsie użytkownika usługi GitHub.

  • W przypadku żądań ściągnięcia są one wyświetlane na karcie Konwersacje żądania ściągnięcia.
  • W przypadku poszczególnych zatwierdzeń są one wyświetlane po umieszczeniu wskaźnika myszy na znaczniku stanu po czasie zatwierdzania na karcie zatwierdzeń repozytorium.

Połączenia PAT lub OAuth w usłudze GitHub

W przypadku potoków korzystających z połączeń PAT lub OAuth w usłudze GitHub stany są publikowane z powrotem do zatwierdzenia/żądania ściągnięcia, które wyzwoliły przebieg. Interfejs API stanu usługi GitHub służy do publikowania takich aktualizacji. Te stany zawierają ograniczone informacje: stan potoku (niepowodzenie, powodzenie), adres URL umożliwiający powrót do potoku kompilacji oraz krótki opis stanu.

Stany połączeń PAT lub OAuth w usłudze GitHub są wysyłane tylko na poziomie przebiegu. Innymi słowy, można zaktualizować jeden stan dla całego przebiegu. Jeśli masz wiele zadań w przebiegu, nie możesz opublikować oddzielnego stanu dla każdego zadania. Jednak wiele potoków może publikować oddzielne stany do tego samego zatwierdzenia.

Testy w usłudze GitHub

W przypadku potoków skonfigurowanych przy użyciu aplikacji GitHub usługi Azure Pipelines stan jest publikowany z powrotem w postaci kontroli usługi GitHub. Funkcja Sprawdzania w usłudze GitHub umożliwia wysyłanie szczegółowych informacji o stanie i testowaniu potoku, pokryciu kodu i błędach. Interfejs API sprawdzania usługi GitHub można znaleźć tutaj.

Dla każdego potoku korzystającego z aplikacji GitHub kontrole są publikowane z powrotem dla całego przebiegu i każdego zadania w tym uruchomieniu.

Usługa GitHub umożliwia trzy opcje, gdy co najmniej jedno sprawdzanie przebiegów kończy się niepowodzeniem dla żądania ściągnięcia/zatwierdzenia. Możesz wybrać opcję "ponownego uruchomienia" pojedynczej kontroli, ponownie uruchomić wszystkie testy zakończone niepowodzeniem dla tego żądania ściągnięcia/zatwierdzenia lub ponownie uruchomić wszystkie kontrole, niezależnie od tego, czy zakończyły się one początkowo powodzeniem, czy nie.

Ponowne uruchamianie testów w usłudze GitHub

Kliknięcie linku "Uruchom ponownie" obok pola Sprawdź nazwę uruchomienia spowoduje ponowienie próby uruchomienia usługi Azure Pipelines, które wygenerowało polecenie Sprawdź przebieg. Wynikowy przebieg będzie miał ten sam numer uruchomienia i będzie używać tej samej wersji kodu źródłowego, konfiguracji i pliku YAML co początkowa kompilacja. Tylko te zadania, które zakończyły się niepowodzeniem w początkowym uruchomieniu, a wszystkie zależne zadania podrzędne zostaną uruchomione ponownie. Kliknięcie linku "Uruchom ponownie wszystkie testy zakończone niepowodzeniem" będzie miało taki sam efekt. Jest to takie samo zachowanie, jak kliknięcie przycisku "Ponów próbę uruchomienia" w interfejsie użytkownika usługi Azure Pipelines. Kliknięcie przycisku "Uruchom ponownie wszystkie kontrole" spowoduje uruchomienie nowego przebiegu z nowym numerem przebiegu i spowoduje odebranie zmian w konfiguracji lub pliku YAML.

Ograniczenia

  • Aby uzyskać najlepszą wydajność, zalecamy maksymalnie 50 potoków w jednym repozytorium. Aby uzyskać akceptowalną wydajność, zalecamy maksymalnie 100 potoków w jednym repozytorium. Czas wymagany do przetworzenia wypychania do repozytorium zwiększa się wraz z liczbą potoków w tym repozytorium. Za każdym razem, gdy istnieje wypychanie do repozytorium, usługa Azure Pipelines musi załadować wszystkie potoki YAML w tym repozytorium, aby dowiedzieć się, czy którykolwiek z nich musi zostać uruchomiony, a załadowanie każdego potoku wiąże się z karą za wydajność. Oprócz problemów z wydajnością zbyt wiele potoków w jednym repozytorium może prowadzić do ograniczenia przepustowości po stronie usługi GitHub, ponieważ usługa Azure Pipelines może wysyłać zbyt wiele żądań w krótkim czasie.

  • Użycie rozszerzeń i dołączania szablonów w potoku ma wpływ na szybkość, z jaką usługa Azure Pipelines wysyła żądania interfejsu API usługi GitHub i może prowadzić do ograniczania przepustowości po stronie usługi GitHub. Przed uruchomieniem potoku usługa Azure Pipelines musi wygenerować kompletny kod YAML, więc musi pobrać wszystkie pliki szablonu.

  • Usługa Azure Pipelines ładuje maksymalnie 2000 gałęzi z repozytorium do list rozwijanych w portalu usługi Azure DevOps, na przykład w oknie Wybieranie gałęzi dla gałęzi Domyślne dla ustawienia ręcznej i zaplanowanej kompilacji lub podczas wybierania gałęzi podczas ręcznego uruchamiania potoku.

    Jeśli na liście nie widzisz żądanej gałęzi, wpisz żądaną nazwę gałęzi ręcznie w polu Domyślna gałąź dla ręcznie i zaplanowanych kompilacji .

    Jeśli klikniesz wielokropek i otworzysz okno dialogowe Wybieranie gałęzi i zamknij ją bez wybrania prawidłowej gałęzi z listy rozwijanej, może zostać wyświetlony komunikat Niektóre ustawienia wymagają uwagi, a to ustawienie jest wymagane poniżej domyślnej gałęzi w przypadku kompilacji ręcznych i zaplanowanych. Aby obejść ten komunikat, otwórz ponownie potok i wprowadź nazwę bezpośrednio w gałęzi Domyślnej dla ręcznej i zaplanowanej kompilacji .

Często zadawane pytania

Problemy związane z integracją z usługą GitHub należą do następujących kategorii:

  • Typy połączeń: nie mam pewności, jakiego typu połączenia używam do łączenia potoku z usługą GitHub.
  • 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.
  • Brak aktualizacji stanu: Moje żądania ściągnięcia w usłudze GitHub są zablokowane, ponieważ usługa Azure Pipelines nie zgłosiła aktualizacji stanu.

Typy połączeń

Aby rozwiązać problemy z wyzwalaczami, jak mogę znać typ połączenia Usługi GitHub używanego dla mojego potoku?

Rozwiązywanie problemów z wyzwalaczami bardzo zależy od typu połączenia usługi GitHub używanego w potoku. Istnieją dwa sposoby określania typu połączenia — z usługi GitHub i z usługi Azure Pipelines.

  • W usłudze GitHub: jeśli repozytorium jest skonfigurowane do korzystania z aplikacji GitHub, stanami żądania ściągnięcia i zatwierdzeniami będą Sprawdzanie przebiegów. Jeśli repozytorium ma skonfigurowaną usługę Azure Pipelines z połączeniami OAuth lub PAT, stanami będzie "stary" styl stanów. Szybkim sposobem określenia, czy stanami są Sprawdzanie przebiegów lub prostych stanów, jest sprawdzenie karty "konwersacja" w żądaniu ściągnięcia w usłudze GitHub.

    • Jeśli link "Szczegóły" przekierowuje do karty Sprawdzanie, jest to polecenie Sprawdź przebieg, a repozytorium korzysta z aplikacji.
    • Jeśli link "Szczegóły" przekierowuje do potoku usługi Azure DevOps, stan to "stary styl", a repozytorium nie korzysta z aplikacji.

  • W usłudze Azure Pipelines: możesz również określić typ połączenia, sprawdzając potok w interfejsie użytkownika usługi Azure Pipelines. Otwórz edytor potoku. Wybierz pozycję Wyzwalacze , aby otworzyć edytor klasyczny potoku. Następnie wybierz kartę YAML , a następnie krok Pobierz źródła . Zauważysz transparent Autoryzowane przy użyciu połączenia: wskazuje połączenie z usługą, które zostało użyte do zintegrowania potoku z usługą GitHub. Nazwa połączenia usługi jest hiperlinkiem. Wybierz ją, aby przejść do właściwości połączenia z usługą. Właściwości połączenia z usługą będą wskazywać typ używanego połączenia:

    • Aplikacja Usługi Azure Pipelines wskazuje połączenie aplikacji GitHub
    • oauth wskazuje połączenie OAuth
    • personalaccesstoken wskazuje uwierzytelnianie pat

Jak mogę przełączyć potok, aby użyć aplikacji GitHub zamiast protokołu OAuth?

Korzystanie z aplikacji GitHub zamiast połączenia OAuth lub PAT jest zalecaną integracją między usługami GitHub i Azure Pipelines. Aby przełączyć się do aplikacji GitHub, wykonaj następujące kroki:

  1. Przejdź tutaj i zainstaluj aplikację w organizacji repozytorium GitHub.
  2. Podczas instalacji nastąpi przekierowanie do usługi Azure DevOps, aby wybrać organizację i projekt usługi Azure DevOps. Wybierz organizację i projekt zawierający klasyczny potok kompilacji, dla którego chcesz użyć aplikacji. Ten wybór kojarzy instalację aplikacji GitHub z organizacją usługi Azure DevOps. Jeśli wybierzesz niepoprawnie, możesz odwiedzić tę stronę , aby odinstalować aplikację GitHub z organizacji GitHub i zacząć od nowa.
  3. Na następnej wyświetlonej stronie nie trzeba kontynuować tworzenia nowego potoku.
  4. Edytuj potok, odwiedzając stronę Potoki (np. https://dev.azure.com/YOUR_ORG_NAME/YOUR_PROJECT_NAME/_build), wybierając potok, a następnie klikając pozycję Edytuj.
  5. Jeśli jest to potok YAML, wybierz menu Wyzwalacze , aby otworzyć edytor klasyczny.
  6. Wybierz krok "Pobierz źródła" w potoku.
  7. Na zielonym pasku z tekstem "Autoryzowane przy użyciu połączenia" wybierz pozycję "Zmień" i wybierz połączenie aplikacji GitHub o takiej samej nazwie jak organizacja usługi GitHub, w której zainstalowano aplikację.
  8. Na pasku narzędzi wybierz pozycję "Zapisz i kolejkę", a następnie pozycję "Zapisz i kolejkę". Wybierz link do przebiegu potoku, który został w kolejce, aby upewnić się, że przebieg zakończył się pomyślnie.
  9. Utwórz (lub zamknij i otwórz ponownie) żądanie ściągnięcia w repozytorium GitHub, aby sprawdzić, czy kompilacja została pomyślnie w kolejce w sekcji "Testy".

Dlaczego nie jest wyświetlane repozytorium GitHub do wyboru w usłudze Azure Pipelines?

W zależności od typu uwierzytelniania i własności repozytorium wymagane są określone uprawnienia.

  • Jeśli używasz aplikacji GitHub, zobacz Uwierzytelnianie aplikacji GitHub.
  • Jeśli używasz protokołu OAuth, zobacz Uwierzytelnianie OAuth.
  • Jeśli używasz punktów dostępu uprzywilejowanego, zobacz Uwierzytelnianie osobistego tokenu dostępu (PAT).

Po wybraniu repozytorium podczas tworzenia potoku występuje błąd "Repozytorium {repo-name} jest używane z aplikacją GitHub usługi Azure Pipelines w innej organizacji usługi Azure DevOps".

Oznacza to, że repozytorium jest już skojarzone z potokiem w innej organizacji. Zdarzenia ciągłej integracji i żądania ściągnięcia z tego repozytorium nie będą działać, ponieważ zostaną one dostarczone do innej organizacji. Poniżej przedstawiono kroki, które należy wykonać, aby usunąć mapowanie do innej organizacji przed przejściem do utworzenia potoku.

  1. Otwórz żądanie ściągnięcia w repozytorium GitHub i utwórz komentarz /azp where. Spowoduje to zamapowanie repozytorium na organizację usługi Azure DevOps.

  2. Aby zmienić mapowanie, odinstaluj aplikację z organizacji GitHub i zainstaluj ją ponownie. Podczas ponownej instalacji upewnij się, że wybrano poprawną organizację po przekierowaniu do usługi Azure DevOps.

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 używasz połączenia aplikacji GitHub w celu połączenia potoku z usługą GitHub? Zobacz Typy połączeń, aby określić typ posiadanego połączenia. Jeśli używasz połączenia aplikacji GitHub, wykonaj następujące kroki:

    • Czy mapowanie jest poprawnie skonfigurowane między usługą GitHub i usługą Azure DevOps? Otwórz żądanie ściągnięcia w repozytorium GitHub i utwórz komentarz /azp where. Spowoduje to zamapowanie repozytorium na organizację usługi Azure DevOps.

      • Jeśli żadna organizacja nie jest skonfigurowana do tworzenia tego repozytorium przy użyciu aplikacji, przejdź do https://github.com/<org_name>/<repo_name>/settings/installations i ukończ konfigurację aplikacji.

      • Jeśli zgłoszono inną organizację usługi Azure DevOps, ktoś utworzył już potok dla tego repozytorium w innej organizacji. Obecnie mamy ograniczenie, które możemy mapować tylko repozytorium GitHub na pojedynczą jedną witrynę DevOps. Tylko potoki w pierwszej organizacji usługi Azure DevOps mogą być wyzwalane automatycznie. Aby zmienić mapowanie, odinstaluj aplikację z organizacji GitHub i zainstaluj ją ponownie. Podczas ponownej instalacji upewnij się, że wybrano poprawną organizację po przekierowaniu do usługi Azure DevOps.

  • Czy używasz protokołu OAuth lub pat do łączenia potoku z usługą GitHub? Zobacz Typy połączeń, aby określić typ posiadanego połączenia. Jeśli używasz połączenia z usługą GitHub, wykonaj następujące kroki:

    1. Połączenia OAuth i PAT opierają się na elementach webhook w celu przekazywania aktualizacji do usługi Azure Pipelines. W usłudze GitHub przejdź do ustawień repozytorium, a następnie do pozycji Elementy webhook. Sprawdź, czy elementy webhook istnieją. Zazwyczaj powinny być widoczne trzy elementy webhook — wypychanie, pull_request i issue_comment. Jeśli tego nie zrobisz, musisz ponownie utworzyć połączenie z usługą i zaktualizować potok, aby używał nowego połączenia z usługą.

    2. Wybierz poszczególne elementy webhook w usłudze GitHub i sprawdź, czy ładunek odpowiadający zatwierdzeniu użytkownika istnieje i został pomyślnie wysłany do usługi Azure DevOps. W tym miejscu może zostać wyświetlony błąd, jeśli nie można przekazać zdarzenia do usługi Azure DevOps.

  • Ruch z usługi Azure DevOps może być ograniczany przez usługę GitHub. Gdy usługa Azure Pipelines odbiera powiadomienie z usługi GitHub, próbuje skontaktować się z usługą GitHub i pobrać więcej informacji o repozytorium i pliku YAML. Jeśli masz repozytorium z dużą liczbą aktualizacji i żądań ściągnięcia, to wywołanie może zakończyć się niepowodzeniem z powodu takiego ograniczania przepustowości. W takim przypadku sprawdź, czy można zmniejszyć częstotliwość kompilacji przy użyciu filtrowania wsadowego lub bardziej rygorystycznej ścieżki/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 wykonaj kroki rozwiązywania problemów w poprzednim pytaniu, a 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? Zwykle można sprawdzić opóźnienie, 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. Oto kilka powodów, dla których może wystąpić opóźnienie:

    • 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.
    • Repozytorium zawiera zbyt wiele potoków YAML. Aby uzyskać najlepszą wydajność, zalecamy maksymalnie 50 potoków w jednym repozytorium. Aby uzyskać akceptowalną wydajność, zalecamy maksymalnie 100 potoków w jednym repozytorium. Tym więcej potoków jest, tym wolniej przetwarzasz wypychanie do tego repozytorium. Za każdym razem, gdy istnieje wypychanie do repozytorium, usługa Azure Pipelines musi załadować wszystkie potoki YAML w tym repozytorium, aby ustalić, czy którykolwiek z nich musi zostać uruchomiony, a każdy nowy potok ponosi karę za wydajność.

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.

Nieudane wyewidencjonowanie

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

remote: Repository not found.
fatal: repository <repo> not found

Może to być spowodowane awarią usługi GitHub. Spróbuj uzyskać dostęp do repozytorium w usłudze GitHub i upewnij się, że jesteś w stanie.

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.

Brak aktualizacji stanu

Moje żądanie ściągnięcia w usłudze GitHub jest zablokowane, ponieważ usługa Azure Pipelines nie zaktualizowała stanu.

Może to być błąd przejściowy, który spowodował, że usługa Azure DevOps nie mogła komunikować się z usługą GitHub. Spróbuj ponownie zaewidencjonować usługę GitHub, jeśli używasz aplikacji GitHub. Możesz też przeprowadzić trywialną aktualizację żądania ściągnięcia, aby sprawdzić, czy problem można rozwiązać.