Udostępnij za pośrednictwem


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 wypchnięte zatwierdzenie. Dzieje się to również w odpowiedzi na wyzwalacze wewnętrzne, na przykład w celu sprawdzenia, czy istnieją zmiany kodu, i uruchomienie zaplanowanego uruchomienia, czy nie. Pobieranie kodu źródłowego może zakończyć się niepowodzeniem z wielu powodów, a częste ograniczanie żądań przez dostawcę repozytorium Git. Istnienie przebiegu informacyjnego nie musi 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 uruchomienie potoku informacyjnego.

Przebieg informacyjny można rozpoznać przy użyciu 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 przebiegu zwykle zawiera błąd BitBucket/GitHub, który spowodował niepowodzenie ładowania potoku YAML
  • Brak etapów/zadań/kroków

Kiedy jest tworzony przebieg informacyjny?

Pierwszym krokiem uruchamiania potoku YAML jest pobranie kodu źródłowego. Gdy ten krok zakończy się niepowodzeniem, system utworzy przebieg informacyjny. Te przebiegi są tworzone tylko wtedy, gdy kod potoku znajduje się w repozytorium GitHub lub BitBucket.

Pobieranie kodu YAML potoku może zakończyć się niepowodzeniem z powodu:

  • Dostawca repozytorium, u którego wystąpiła awaria
  • Ograniczanie żądań
  • Problemy z uwierzytelnianiem
  • Nie można pobrać zawartości pliku potoku .yml

Potok może działać w odpowiedzi na:

  • Wypycha do gałęzi na liście trigger gałęzi
  • Tworzenie lub aktualizowanie żądań ściągnięcia przeznaczonych dla gałęzi na pr liście gałęzi
  • Zaplanowane przebiegi
  • Elementy webhook o nazwie
  • Aktualizacje repozytorium zasobów
  • Ukończono kompilacje zewnętrzne zasobów
  • Potoki zasobów są ukończone
  • Dostępne są nowe wersje pakietów zasobów
  • Zmiany kontenerów zasobów

Oto przykład tworzenia przebiegu informacyjnego. Załóżmy, że masz repozytorium na lokalnym serwerze BitBucket i potok, który kompiluje kod w tym repozytorium. Załóżmy, że zaplanowano uruchamianie potoku codziennie o godzinie 03:00. Wyobraź sobie, że jest to 03:00, a serwer BitBucket ma awarię. Usługa Azure DevOps dociera do lokalnego serwera BitBucket, aby pobrać kod YAML potoku, ale nie może z powodu awarii. W tej chwili system tworzy przebieg informacyjny podobny do przedstawionego na poprzednim zrzucie ekranu.

Ograniczanie żądań przez dostawcę repozytorium Git jest częstą przyczyną Azure DevOps Services utworzenia przebiegu informacyjnego. Ograniczanie występuje, gdy usługa Azure DevOps wysyła zbyt wiele żądań do repozytorium w krótkim czasie. Te żądania mogą być spowodowane na przykład gwałtownym wzrostem aktywności zatwierdzania. Problemy z ograniczaniem przepustowości są przejściowe.

Następne kroki

Dowiedz się więcej o wyzwalaczach i tworzeniu repozytoriów GitHub lub BitBucket .