Udostępnij za pośrednictwem

Tworzenie repozytoriów usługi Bitbucket Cloud

  • Artykuł

Azure DevOps Services

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

Bitbucket i Azure Pipelines to dwie niezależne usługi, które dobrze się integrują. Użytkownicy usługi Bitbucket Cloud nie uzyskują automatycznie dostępu do usługi Azure Pipelines. Należy je jawnie dodać do usługi Azure Pipelines.

Dostęp do repozytoriów usługi Bitbucket

Utwórz nowy potok, wybierając najpierw repozytorium Bitbucket Cloud, 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 pobrania kodu podczas kompilacji. Ponadto użytkownik konfigurujący potok musi mieć dostęp administratora do aplikacji Bitbucket, ponieważ ta tożsamość jest używana do rejestrowania elementu webhook w usłudze Bitbucket.

Istnieją 2 typy uwierzytelniania do udzielania usłudze Azure Pipelines dostępu do repozytoriów usługi Bitbucket Cloud podczas tworzenia potoku.

Typ uwierzytelniania Potoki są uruchamiane przy użyciu polecenia
1. OAuth Twoja osobista tożsamość usługi Bitbucket
2. nazwa użytkownika i hasło Twoja osobista tożsamość usługi Bitbucket

Uwierzytelnianie OAuth

OAuth to najprostszy typ uwierzytelniania, z który można rozpocząć pracę z repozytoriami na koncie usługi Bitbucket. Aktualizacje stanu bitbucket będą wykonywane w imieniu osobistej tożsamości usługi Bitbucket. Aby potoki działały, dostęp do repozytorium musi pozostać aktywny.

Aby użyć protokołu OAuth, zaloguj się do usługi Bitbucket po wyświetleniu monitu podczas tworzenia potoku. Następnie kliknij Autoryzuj autoryzowanie za pomocą protokołu OAuth. Połączenie OAuth zostanie zapisane w projekcie usługi Azure DevOps do późniejszego użycia, a także użyte w tworzonym potoku.

Uwaga

Maksymalna liczba repozytoriów Bitbucket, które interfejs użytkownika usługi Azure DevOps Services może załadować, wynosi 2000.

Uwierzytelnianie przy użyciu hasła

Kompilacje i aktualizacje stanu bitbucket będą wykonywane w imieniu Twojej tożsamości osobistej. Aby kompilacje nadal działały, dostęp do repozytorium musi pozostać aktywny.

Aby utworzyć połączenie z hasłem, odwiedź stronę Połączenia usługi w ustawieniach projektu usługi Azure DevOps. Utwórz nowe połączenie usługi Bitbucket i podaj nazwę użytkownika i hasło, aby nawiązać połączenie z repozytorium Usługi Bitbucket Cloud.

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.

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żyć 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 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ż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 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

Uwaga

batch nie jest obsługiwany 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.

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

Uwaga

W przypadku repozytoriów usługi Bitbucket Cloud użycie składni branches jest jedynym sposobem określania wyzwalaczy tagów. Składnia tags: nie jest obsługiwana w przypadku usługi Bitbucket.

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

Odgałęzienia

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 master 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 master) lub symbol wieloznaczny (na przykład releases/*).

Uwaga

Nie można użyć 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.

Każde nowe uruchomienie tworzy najnowsze zatwierdzenie z gałęzi źródłowej żądania ściągnięcia. Różni się to od tego, jak usługa Azure Pipelines tworzy żądania ściągnięcia w innych repozytoriach (np. azure Repos lub GitHub), gdzie kompiluje zatwierdzenie scalania. Niestety, bitbucket nie ujawnia informacji o zatwierdzeniu scalania, który zawiera scalony kod między gałęziami źródłowymi i docelowymi żądania ściągnięcia.

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

Po określeniu wyzwalacza pr zastępuje on domyślny niejawny wyzwalacz pr i wypycha tylko do gałęzi, które są jawnie skonfigurowane do dołączania, spowoduje wyzwolenie potoku.

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.

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

  • Symbole wieloznaczne nie są obsługiwane w przypadku 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).

Wiele aktualizacji żądania ściągnięcia

Można określić, czy dodatkowe aktualizacje żądania ściągnięcia powinny 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

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 .

Uwaga

Jeśli wyzwalacz pr nie jest wyzwalany, upewnij się, że nie zastąpić wyzwalaczy żądania ściągnięcia YAML w interfejsie użytkownika.

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.

Ograniczenia

Usługa Azure Pipelines ładuje maksymalnie 2000 gałęzi z repozytorium do list rozwijanych w portalu usługi Azure Devops, na przykład w gałęzi Default dla ręcznych i zaplanowanych kompilacji ustawienie 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.

Często zadawane pytania

Problemy związane z integracją rozwiązania Bitbucket należą do następujących kategorii:

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.

  • Elementy webhook są używane do przekazywania aktualizacji z usługi Bitbucket do usługi Azure Pipelines. W aplikacji Bitbucket przejdź do ustawień repozytorium, a następnie do pozycji Elementy webhook. Sprawdź, czy elementy webhook istnieją.

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

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

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

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

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

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

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

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

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

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

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

Nie chcę, aby użytkownicy zastąpili listę gałęzi wyzwalaczy podczas aktualizowania pliku YAML. 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.

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.