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 rozwiązania 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 self repozytorium. Domyślnie jest to repozytorium kompilowane przez potok.

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

Usługa Azure Pipelines musi mieć dostęp do repozytoriów w celu 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.

Authentication type Potoki są uruchamiane przy użyciu polecenia
1. Uwierzytelnianie 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 pozycję Autoryzuj, aby autoryzować 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 hasłem

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

Odgałęzienia

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

trigger:
- main
- releases/*

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

Uwaga

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

Uwaga

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

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

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

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

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

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

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

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

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

Ważne

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

Wsadowe przebiegi ciągłej integracji

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

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

Uwaga

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

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

Uwaga

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

Ścieżki

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

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

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

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

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

Uwaga

W przypadku repozytoriów usługi Bitbucket Cloud używanie branches składni jest jedynym sposobem określania wyzwalaczy tagów. Składnia nie jest obsługiwana tags: przez 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 dołączyć [skip ci] komunikat lub opis dowolnego zatwierdzenia, które są częścią wypychania, a usługa Azure Pipelines pominą uruchamianie ciągłej integracji dla tego wypychania. Można również użyć dowolnej z następujących odmian.

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

Używanie typu wyzwalacza w warunkach

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

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

Zachowanie wyzwalaczy podczas tworzenia nowych gałęzi

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

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

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

Symbole wieloznaczne

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

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

Wyzwalacze żądania ściągnięcia

Wyzwalacze żądania ściągnięcia powodują uruchomienie potoku za każdym razem, gdy żądanie ściągnięcia zostanie otwarte z jedną z określonych gałęzi docelowych lub gdy aktualizacje zostaną wprowadzone do takiego żądania ściągnięcia.

Odgałęzienia

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

pr:
- main
- releases/*

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

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

Uwaga

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

Uwaga

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

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 pr wyzwalacze, walidacje żądań ściągnięcia są automatycznie włączone dla wszystkich gałęzi, tak jak w przypadku napisano następujący pr wyzwalacz. Ta konfiguracja wyzwala kompilację po utworzeniu dowolnego żądania ściągnięcia, a gdy zatwierdzenia wchodzą do gałęzi źródłowej dowolnego aktywnego żądania ściągnięcia.

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

Ważne

Po określeniu pr wyzwalacza zastępuje on domyślny niejawny pr wyzwalacz 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ą wrażliwe na wielkość liter. Pamiętaj, aby użyć tego samego przypadku co rzeczywiste foldery.
  • Nie można używać zmiennych w ścieżkach, ponieważ zmienne są oceniane w czasie wykonywania (po wyzwoleniu wyzwalacza).

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 w schemacie YAML.

Uwaga

pr Jeśli wyzwalacz nie jest wyzwalany, upewnij się, że nie zastąpiono 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.

Screenshot of an informational pipeline run.

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

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

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

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 domyślnej gałęzi ręcznej i zaplanowanej kompilacji lub podczas wybierania gałęzi podczas ręcznego uruchamiania potoku. Jeśli na liście nie widzisz żądanej gałęzi, wpisz żądaną nazwę gałęzi ręcznie.

Często zadawane pytania

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

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

Wyzwalacze zakończone niepowodzeniem

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

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

  • 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. W jaki sposób to zrobić?

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

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

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

Nieprawidłowa wersja

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

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