Udostępnij za pośrednictwem

Tworzenie repozytoriów GitHub

  • Artykuł

usługi 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 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.

Organizacji

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

struktura organizacji usługi GitHub

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

struktury organizacji usługi Azure DevOps

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

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

struktura usługi GitHub zamapowana na Usługi 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 po organizacji i repozytorium GitHub, 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 Adres URL
GitHub https://github.com/python/cpython
Azure DevOps https://dev.azure.com/python/cpython

Użytkowników

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 usługi GitHub znajdują się w https://github.com/orgs/your-organization/people (zastąp your-organization).

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

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
Menedżer rozliczeń Członek Project Collection Administrators
Członek Członek Project Collection Valid Users. Domyślnie grupa Członek nie ma uprawnień do tworzenia nowych projektów. Aby zmienić uprawnienie, ustaw uprawnienia Create new projects grupy na Allowlub 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 https://dev.azure.com/your-organization/_settings/security (zastąp your-organization).

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 znajdują się w https://github.com/your-organization/your-repository/settings/collaboration (zastąp your-organization i your-repository).

Uprawnienia projektu DevOps znajdują się w 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
Admin Członek Project Administrators
Pisać Członek Contributors
Czytać Członek Readers

Jeśli repozytorium GitHub udziela uprawnień zespołom, możesz utworzyć pasujące zespoły w sekcji Teams 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ę Security.
  4. Wybierz pozycję Dodaj... dodać określonego użytkownika, zespołu lub grupy i dostosować ich 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 repozytorium self. 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 wielu repozytoriów.

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 Współpracuje z usługą GitHub Checks
1. aplikacji GitHub Tożsamość usługi Azure Pipelines Tak
2. 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 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świetlania 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. Jeśli jednak aplikacja jest zainstalowana dla wszystkich repozytoriów, token używany przez aplikację będzie miał dostęp do wszystkich repozytoriów, w tym prywatnych. Ze względów bezpieczeństwa zaleca się oddzielenie prywatnych i publicznych repozytoriów na poziomie organizacji. Oznacza to, że organizacja dedykowana jest przeznaczona tylko dla projektów publicznych bez repozytoriów prywatnych. Jeśli z jakiegoś powodu istnieje potrzeba posiadania repozytoriów publicznych i prywatnych w tej samej organizacji, zamiast używania dostępu do wszystkich repozytoriów, jawnie wybierz repozytoria, do których aplikacja powinna mieć dostęp. Wymaga to większej ilości pracy dla administratorów, ale zapewnia lepsze zarządzanie zabezpieczeniami.

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:

Pozwolenie 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

OAuth jest najprostszym typem 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 Potoki > Połączenia usługi > Nowe połączenie z usługą > GitHub > Autoryzuj. 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 Potoki > Połączenia usługi > Nowe połączenie z usługą > GitHub > Autoryzuj. 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 Potoki > Połączenia usługi > Nowe połączenie z usługą > GitHub > Autoryzuj. 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 Potoki > Połączenia usługi > Nowe połączenie z usługą > GitHub > Autoryzuj. 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 korzystania z 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żna go również usunąć z listy połączeń usługi GitHub w ustawieniach projektu usługi Azure DevOps.

Uwierzytelnianie osobistego tokenu dostępu (PAT)

pats są rzeczywiście takie same jak OAuth, ale umożliwiają kontrolowanie uprawnień przyznanych 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ć token pat, odwiedź stronę Osobiste tokeny dostępu w ustawieniach usługi GitHub. Wymagane uprawnienia to repo, admin:repo_hook, read: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_hook, read: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_hook, read: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ę we własnej organizacji usługi GitHub, musi mieć wymagane zakresy dostępu w obszarze Osobiste tokeny dostępu: repo, admin:repo_hook, read: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_hook, read: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 używania 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żna go również usunąć 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 przy użyciu wyzwalacza ciągłej integracji we wszystkich gałęziach, chyba że ustawienie Wyłącz sugerowaną ci wyzwalacz YAML wprowadzone w przebiegu usługi Azure DevOps 227jest włączone. Ustawienie Wyłącz dorozumianą ci wyzwalacz YAML CI można skonfigurować na poziomie organizacji lub na poziomie projektu. Po włączeniu ustawienia Wyłącz sugerowany wyzwalacz CI YAML wyzwalacze ciągłej integracji dla potoków YAML nie są włączone, jeśli potok YAML nie ma sekcji trigger. Domyślnie nie włączono Wyłącz sugerowany wyzwalacz CI YAML.

Oddziałów

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.

Nuta

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

Nuta

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 korzystających z exclude lub batchnależ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 wydań. Nie zostanie jednak wyzwolony, jeśli zostanie wprowadzona zmiana w gałęzi wydania rozpoczynającej się od old.

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

Oprócz określania nazw gałęzi na listach branches 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żny

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 ustawisz batch na true, gdy potok jest uruchomiony, system czeka na ukończenie przebiegu, a następnie uruchamia kolejne uruchomienie ze wszystkimi zmianami, które nie zostały jeszcze skompilowane.

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

Nuta

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

Aby wyjaśnić ten przykład, powiedzmy, że A wypychania, aby main spowodował 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.

Nuta

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, aby filtrować wszystkie gałęzie 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*. Podczas określania filtrów ścieżek można użyć symboli wieloznacznych (**, *lub ?).

  • Ś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ą uwzględniane w wielkości liter. Pamiętaj, aby użyć tego samego przypadku co rzeczywiste foldery.
  • Nie można użyć zmiennych w ścieżkach, ponieważ zmienne są oceniane w czasie wykonywania (po wyzwoleniu wyzwalacza).

Tagi

Oprócz określania tagów na listach branches, 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żny

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żny

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 uwzględnić [skip ci] w komunikacie lub opisie 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. Na przykład po wypchnięciu aktualizacji do folderu docs może być wyzwalany jeden potok, 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ą * dopasowania do zera lub większej liczby znaków i ? w celu dopasowania do pojedynczego znaku.

  • Jeśli zaczniesz wzorzec od * 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 użyć * lub ?.
    • W usłudze Azure DevOps Server 2020 i niższym można uwzględnić * jako końcowy znak, ale nie różni się od samodzielnego określania nazwy katalogu. Możesz nie uwzględnić * w środku filtru ścieżki i nie można użyć ?.
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.

Oddziałów

Gałęzie docelowe można określić podczas sprawdzania poprawności żądań ściągnięcia. Na przykład w celu zweryfikowania żądań ściągnięcia docelowych main i releases/*można użyć następującego wyzwalacza pr.

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/*).

Nuta

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

Nuta

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 ref podczas tworzenia żądania ściągnięcia. Odwołanie wskazuje na zatwierdzenie scalania , czyli scalony kod między gałęziami źródłowymi i docelowymi żądania ściągnięcia. Potok weryfikacji żądania ściągnięcia tworzy zatwierdzenie, do którego wskazuje ten ref. 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 wyzwalacze pr, walidacje żądań ściągnięcia są automatycznie włączone dla wszystkich gałęzi, tak jak w przypadku następującego wyzwalacza pr. 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żny

Po określeniu wyzwalacza pr 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, że docelowa main lub releases/*, a releases/old* gałęzi 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 dotyczące :

  • 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 Stan neutralny post do usługi GitHub, gdy kompilacja zostanie pominięta.
  • symbole wieloznaczne są teraz obsługiwane przy użyciu 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ą uwzględniane w wielkości liter. Pamiętaj, aby użyć tego samego przypadku co rzeczywiste foldery.
  • Nie można użyć 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 właściwość drafts na false.

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

Nuta

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

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 zatwierdzenia scalania (scalony kod między gałęziami źródłowymi i docelowymi żądania ściągnięcia), niezależnie od tego, czy istnieją wypychane 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 żadnych 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 konfigurowania chronionych gałęzi w ustawieniach repozytorium.

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

    sprawdzanie stanu potoku usługi GitHub

Ważny

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 upublicznić 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 Validate contributions from forks.
  • dostęp między projektami: Wszystkie potoki w publicznym projekcie usługi Azure DevOps 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 źródeł danych pakietów.

Współtworzenie rozwidlenia

Ważny

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ę Pipelines, 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 Kompiluj żądania ściągnięcia z rozwidlenia tego repozytorium pole wyboru.

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ą:

  • Token zabezpieczający z dostępem do repozytorium GitHub.
  • Te elementy, jeśli potok używa ich:

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

Nuta

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 kompilacji takie same uprawnienia jak zwykłe kompilacje, włącz Tworzenie kompilacji rozwidlenia mają takie same uprawnienia jak zwykłe kompilacje ustawienie.

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 Ograniczanie żądań ściągnięcia kompilacji z rozwidlonych repozytoriów GitHub kontroli. Jest ona dostępna na poziomie organizacji i projektu. Możesz wybrać następujące opcje:

  • 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 Sprint 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 Limit kompilowania żądań ściągnięcia z rozwidlonych repozytoriów GitHubustawienie Wyłącz kompilowanie żądań ściągnięcia z rozwidlonych repozytoriów.

Po wybraniu 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 kompilacji z rozwidlenia repozytoriów, nie może, aby te kompilacje miały takie same uprawnienia jak normalne kompilacje, a muszą być wyzwalane przez komentarz żądania ściągnięcia. Projekty mogą nadal decydować o tym, nie zezwalać potokom na tworzenie takich reguł ściągnięcia.

Po wybraniu opcji Dostosuj możesz 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ą zdecydować się na nie zezwalać potokom na tworzenie takich reguł ściągnięcia lub tworzenie ich bezpiecznie lub mieć jeszcze bardziej restrykcyjne ustawienia niż określone na poziomie organizacji.

Kontrolka jest wyłączona dla istniejących organizacji. począwszy od września 2023 r. nowe organizacje bezpiecznie kompilować żądania ściągnięcia z rozwidlonych repozytoriów, domyślnie włączone.

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 należy włączać Udostępnianie wpisów tajnych kompilacjom rozwidlenia pole wyboru, 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 weryfikacji żądania ściągnięcia włącz 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 niebędących członkami 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 tylko na żądania ściągnięcia od członków innych niż członkowie zespołu i żądanie ściągnięcia zostanie wykonane 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 przy użyciu /AzurePipelines run lub /AzurePipelines run <pipeline-name>.

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

Polecenie Wynik
/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.

Nuta

Aby uzyskać zwięzłość, możesz komentować przy użyciu /azp zamiast /AzurePipelines.

Ważny

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 prywatnego na publiczny tutaj (zastąp Your-Organization nazwą 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 jest < 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.

Kasa

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.

Nuta

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 przez checkout: none, a następnie użyć zadania skryptu do wykonania własnego 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 System.PreferGitFromPath na wartość 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 checkout za pomocą path. Określona ścieżka jest względna względem $(Agent.BuildDirectory). Na przykład: jeśli wartość ścieżki wyewidencjonowania jest mycustompath, a $(Agent.BuildDirectory) jest C:\agent\_work\1, kod źródłowy zostanie wyewidencjonowany w 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 path, każde repozytorium zostanie umieszczone w podfolderze s nazwanym 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 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 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ć 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ć 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 ani pobierania.

  • uwierzytelnione :

    • 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 o tych opcjach i ich wpływach 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 wyewidencjonowania. 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 wyewidencjonowania modułów podrzędnych, możesz zamiast tego użyć niestandardowego kroku skryptu, aby pobrać moduły podrzędne. Najpierw pobierz osobisty token dostępu (PAT) i prefiks go za pomocą pat:. Następnie kodowanie base64 tym prefiksowym ciągu w celu utworzenia podstawowego tokenu 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.

Nuta

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

Synchronizowanie tagów

Ważny

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 opcji --tags 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 właściwość i w interfejsie użytkownika, konfigurując ustawienie tagów synchronizacji .

Ustawienie można skonfigurować w kroku wyewidencjonowania potoku.

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

steps:
- checkout: self
  fetchTags: true

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

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

    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 tagów synchronizacji .

    Zrzut ekranu przedstawiający ustawienie Tagów synchronizacji.

Nuta

Jeśli jawnie ustawisz fetchTags w kroku checkout, 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., domyślna opcja synchronizacji tagów pozostaje taka sama jak istniejące zachowanie przed dodaniu tagów synchronizacji opcji, co jest true.
  • W przypadku nowych potoków utworzonych po uruchomieniu przebiegu usługi Azure DevOps w wersji 209 domyślna dla tagów synchronizacji jest false.

Nuta

Jeśli jawnie ustawisz fetchTags w kroku checkout, 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 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żny

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

Ustawienie można skonfigurować 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

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

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

    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 pobierania Płytkie. Usuń zaznaczenie Płytkie pobieranie, 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.

Nuta

Jeśli jawnie ustawisz fetchDepth w kroku checkout, 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.

Nuta

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 .

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

Nuta

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 takim przypadku, aby uzyskać najlepszą wydajność, upewnij się, że kompilujesz również przyrostowo, wyłączając wszystkie Wyczyść opcji 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.

Nuta

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

Ustawienie można skonfigurować 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 jest ustawiona na true potok kompilacji wykonuje cofanie wszelkich zmian w $(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ć ustawienie workspace 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.

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

  • zasobów: usuwa i odtwarza $(Build.SourcesDirectory). Spowoduje to zainicjowanie nowego lokalnego repozytorium Git dla każdej kompilacji.

  • wszystkich: usuwa i odtwarza $(Agent.BuildDirectory). 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.

Konfigurowanie opcji 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 format tagu 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 zdefiniować na karcie zmiennych .

Potok kompilacji oznacza ź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 refs/tags/{tag} ref usługi Git 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, są dostępne 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 pat lub połączeń OAuth GitHub stany są publikowane z powrotem do zatwierdzenia/żądania ściągnięcia, które wyzwoliło uruchomienie. 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 usługi Azure Pipelines aplikacji GitHubstan jest ogłaszany 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 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 rozszerza i obejmują szablony w potoku wpływają 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 Wybierz gałąź dla gałęzi Domyślna dla ręcznego i zaplanowanego ustawienia 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 gałęzi Domyślna dla ręcznie i zaplanowanych kompilacji polu.

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

FAQ

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

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 Wyzwalacze, aby otworzyć edytor klasyczny potoku. Następnie wybierz kartę YAML, a następnie krok Pobierz źródła. Zauważysz baner Autoryzowane przy użyciu połączenia: wskazujący 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:

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

Jak przełączyć potok, aby używać 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ć tej stronie, 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 i 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.

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 wyzwalacze ciągłej integracji lub żądania ściągnięcia YAML są zastępowane przez ustawienia potoku winterfejsu użytkownika? Podczas edytowania potoku wybierz pozycję ..., a następnie Wyzwalacze.

    interfejs użytkownika ustawień potoku .

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

    zastąpić wyzwalacz YAML z tego miejsca.

  • 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:

    • Występuje awaria usługi na naszej stronie stanu . 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. Jak 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 wyzwalaczy .
  3. Wybierz zastąpić 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 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 tak jest?

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