Rozwiązywanie problemów z przebiegami potoków

  • Artykuł

Azure DevOps Services | Azure DevOps Server 2022 — Azure DevOps Server 2019

Jeśli uruchomienie potoku nie powiedzie się, możesz użyć informacji diagnostycznych i dzienników dostarczonych przez stronę podsumowania przebiegu potoku, aby rozwiązać problem.

Zrzut ekranu przedstawiający stronę podsumowania przebiegu potoku.

Wyświetlanie dzienników

Wybierz komunikat o błędzie, aby wyświetlić dzienniki zadania, które nie powiodło się.

Zrzut ekranu przedstawiający komunikat o błędzie zadania na stronie podsumowania przebiegu potoku.

Zostanie wyświetlona strona dzienników z wybranym błędem. W tym przykładzie cmd-line w zadaniu występuje błąd, w którym echo polecenie jest wprowadzane jako ech.

Zrzut ekranu przedstawiający dziennik diagnostyczny przebiegu potoku.

Możesz wyświetlić nieprzetworzone dziennik dla zadania, wybierając pozycję Wyświetl nieprzetworzone dzienniki, a następnie przeszukać dziennik przy użyciu polecenia Znajdź.

Zrzut ekranu przedstawiający opcje widoku dziennika w usłudze Azure DevOps.

Przeskanuj dzienniki zadania zakończonego niepowodzeniem, aby uzyskać informacje o błędach i wskazówki, dlaczego zadanie kończy się niepowodzeniem. Domyślnie dzienniki inne niżverbose są generowane przez uruchomienie potoku. Jeśli dzienniki domyślne nie wskazują przyczyny problemu, możesz uzyskać więcej informacji, konfigurując pełne dzienniki.

Strona analizy błędów

Pomoc dotycząca rozwiązywania problemów jest dostępna przy użyciu strony Analiza błędów. Przesuń wskaźnik myszy nad wierszem informacji o błędzie i wybierz ikonę Wyświetl analizę .

Zrzut ekranu przedstawiający ikonę wyświetlania analizy na stronie podsumowania przebiegu potoku.

Zrzut ekranu przedstawiający ikonę wyświetlania analizy dla usługi Azure DevOps Server.

Wybierz pozycję Wyświetl agenta dla własnych agentów (lub Informacje o obrazie hostowanego agenta dla agentów hostowanych przez firmę Microsoft), aby wyświetlić więcej informacji o agencie używanym do uruchamiania potoku, a następnie wyświetl dziennik , aby wyświetlić dzienniki uruchamiania potoku.

Zrzut ekranu przedstawiający stronę analizy błędów w portalu usługi Azure DevOps.

Wybierz nazwę zadania poniżej szczegółów czasu wykonywania, aby wyświetlić informacje o zadaniu.

Zrzut ekranu przedstawiający szczegóły zadania z analizy błędów.

W tym przykładzie widać, że w Value obiekcie Scriptznajduje się błąd . Wybierz pozycję Informacje o tym zadaniu , aby wyświetlić dokumentację zadania.

Jeśli problem nie jest widoczny na stronie podsumowania przebiegu potoku lub przeglądaniu dzienników, zapoznaj się z następującą sekcją Typowe problemy i zobacz Przeglądanie dzienników w celu zdiagnozowania problemów z potokiem, aby uzyskać informacje na temat pobierania pełnych dzienników, które zawierają dodatkowe informacje diagnostyczne.

Typowe problemy

Szczegółowe informacje o zadaniach dla przebiegów potoku, które zakończyły się niepowodzeniem

Usługa Azure DevOps udostępnia ustawienie Szczegółowe informacje zadań dla nieudanych przebiegów potoku, które po włączeniu udostępnia wyskakujące powiadomienia o niepowodzeniach kompilacji z linkiem umożliwiającym wyświetlenie raportu.

Zrzut ekranu przedstawiający metryki szczegółowych informacji o zadaniach.

Aby skonfigurować to ustawienie, przejdź do pozycji Funkcje w wersji zapoznawczej, znajdź pozycję Zadanie Szczegółowe informacje dla przebiegów potoków, które zakończyły się niepowodzeniem, a następnie wybierz odpowiednie ustawienie.

Zrzut ekranu przedstawiający szczegółowe informacje o zadaniach dla ustawienia przebiegów potoku, które zakończyły się niepowodzeniem.

Przekroczenie limitu czasu zadania

Potok może działać przez długi czas, a następnie zakończyć się niepowodzeniem z powodu przekroczenia limitu czasu zadania. Limit czasu zadania jest ściśle zależny od używanego agenta. Bezpłatni agenci hostowani przez firmę Microsoft mają maksymalny limit czasu 60 minut na zadanie dla repozytorium prywatnego i 360 minut dla repozytorium publicznego. Aby zwiększyć maksymalny limit czasu dla zadania, możesz wybrać dowolną z poniższych opcji.

  • Kup agenta hostowanego przez firmę Microsoft, który zapewni 360 minut dla wszystkich zadań niezależnie od używanego repozytorium
  • Użyj własnego agenta, aby wykluczyć wszelkie problemy z przekroczeniem limitu czasu z powodu agenta

Dowiedz się więcej o przekroczeniu limitu czasu zadania.

Uwaga

Jeśli limit czasu zadań agenta hostowanego przez firmę Microsoft przekracza limit czasu, upewnij się, że nie określono limitu czasu potoku, który jest krótszy niż maksymalny limit czasu dla zadania. Aby to sprawdzić, zobacz Limity czasu.

Problemy z pobieraniem kodu

Mój potok kończy się niepowodzeniem w kroku wyewidencjonowania

Jeśli używasz checkout kroku w repozytorium Git usługi Azure Repos w organizacji, które znajduje się w innym projekcie niż potok, upewnij się, że ustawienie Ogranicz zakres autoryzacji zadania do bieżącego projektu jest wyłączone lub wykonaj kroki opisane w temacie Tożsamości kompilacji w zakresie, aby upewnić się, że potok ma dostęp do repozytorium.

Jeśli potok nie może uzyskać dostępu do repozytorium z powodu ograniczonego zakresu autoryzacji zadania, zostanie wyświetlony błąd Git fetch failed with exit code 128 , a dzienniki będą zawierać wpis podobny do Remote: TF401019: The Git repository with name or identifier <your repo name> does not exist or you do not have permissions for the operation you are attempting.

Jeśli potok kończy się niepowodzeniem natychmiast Could not find a project that corresponds with the repository, upewnij się, że nazwa projektu i repozytorium jest poprawna w checkout kroku lub deklaracji zasobu repozytorium.

problemy z Kontrola wersji serwera Team Foundation (TFVC)

Pobieranie źródeł, które nie pobierają niektórych plików

Może to być scharakteryzowane przez komunikat w dzienniku "Wszystkie pliki aktualne" z tf get polecenia . Sprawdź, czy wbudowana tożsamość usługi ma uprawnienia do pobierania źródeł. Usługa kompilacji kolekcji projektów tożsamości lub usługa kompilacji projektu będą potrzebować uprawnień do pobierania źródeł, w zależności od wybranego zakresu autoryzacji na karcie Ogólne potoku kompilacji. W internetowym interfejsie użytkownika kontroli wersji można przeglądać pliki projektu na dowolnym poziomie hierarchii folderów i sprawdzać ustawienia zabezpieczeń.

Pobieranie źródeł za pośrednictwem serwera proxy team foundation

Najprostszym sposobem skonfigurowania agenta w celu pobierania źródeł za pośrednictwem serwera Proxy programu Team Foundation jest ustawienie zmiennej środowiskowej TFSPROXY wskazującej serwer proxy TFVC dla użytkownika uruchomionego jako agenta.

Windows:

    set TFSPROXY=http://tfvcproxy:8081
    setx TFSPROXY=http://tfvcproxy:8081 // If the agent service is running as NETWORKSERVICE or any service account you can't easily set user level environment variable

macOS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

Mój potok kończy się niepowodzeniem w kroku wiersza polecenia, takim jak MSBUILD

Warto zawęzić, czy awaria kompilacji lub wydania jest wynikiem problemu z produktem Azure Pipelines/TFS (agentem lub zadaniami). Błędy kompilacji i wydania mogą również wynikać z poleceń zewnętrznych.

Sprawdź dzienniki pod kątem dokładnego wiersza polecenia wykonywanego przez zadanie, które kończy się niepowodzeniem. Próba uruchomienia polecenia lokalnie z wiersza polecenia może odtworzyć problem. Warto uruchomić polecenie lokalnie z własnej maszyny i/lub zalogować się na maszynie i uruchomić polecenie jako konto usługi.

Na przykład czy problem występuje podczas części msBuild potoku kompilacji (na przykład czy używasz programu MSBuild lub zadania kompilacji programu Visual Studio)? Jeśli tak, spróbuj uruchomić to samo polecenie MSBuild na komputerze lokalnym przy użyciu tych samych argumentów. Jeśli problem można odtworzyć na komputerze lokalnym, następne kroki to zbadanie problemu msBuild.

Układ pliku

Lokalizacja narzędzi, bibliotek, nagłówków i innych elementów potrzebnych do kompilacji może się różnić od hostowanego agenta niż z komputera lokalnego. Jeśli kompilacja nie powiedzie się, ponieważ nie może znaleźć jednego z tych plików, możesz użyć poniższych skryptów, aby sprawdzić układ agenta. Może to pomóc w śledzeniu brakującego pliku.

Utwórz nowy potok YAML w lokalizacji tymczasowej (np. nowe repozytorium utworzone na potrzeby rozwiązywania problemów). Zgodnie z zapisem skrypt wyszukuje katalogi na ścieżce. Opcjonalnie możesz edytować wiersz, SEARCH_PATH= aby wyszukiwać inne miejsca.

# Script for Linux and macOS
pool: { vmImage: ubuntu-latest } # or whatever pool you use
steps:
- checkout: none
- bash: |
    SEARCH_PATH=$PATH  # or any colon-delimited list of paths
    IFS=':' read -r -a PathDirs <<< "$SEARCH_PATH"
    echo "##[debug] Found directories"
    for element in "${PathDirs[@]}"; do
        echo "$element"
    done;
    echo;
    echo;  
    echo "##[debug] Found files"
    for element in "${PathDirs[@]}"; do
        find "$element" -type f
    done

# Script for Windows
pool: { vmImage: windows-2019 } # or whatever pool you use
steps:
- checkout: none
- powershell: |
    $SEARCH_PATH=$Env:Path
    Write-Host "##[debug] Found directories"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Write-Host "$Dir"
    }
    Write-Host ""
    Write-Host ""
    Write-Host "##[debug] Found files"
    ForEach ($Dir in $SEARCH_PATH -split ";") {
      Get-ChildItem $Dir -File -ErrorAction Continue | ForEach-Object -Process {
        Write-Host $_.FullName
      }
    }

Różnice między lokalnym wierszem polecenia a agentem

Należy pamiętać, że niektóre różnice obowiązują podczas wykonywania polecenia na komputerze lokalnym i gdy kompilacja lub wydanie jest uruchomione na agencie. Jeśli agent jest skonfigurowany do uruchamiania jako usługi w systemie Linux, macOS lub Windows, nie jest uruchomiony w ramach interaktywnej sesji logowania. Bez interaktywnej sesji logowania interakcja interfejsu użytkownika i inne ograniczenia istnieją.

Błędy dotyczące pliku lub folderu będącego w użyciu

File or folder in use błędy są często wskazywane przez komunikaty o błędach, takie jak:

  • Access to the path [...] is denied.
  • The process cannot access the file [...] because it is being used by another process.
  • Access is denied.
  • Can't move [...] to [...]

Kroki rozwiązywania problemów:

Wykrywanie plików i folderów w użyciu

W systemie Windows narzędzia, takie jak Monitor procesów, mogą przechwytywać ślad zdarzeń plików w określonym katalogu. Można też użyć narzędzi, takich jak Eksplorator procesów lub Dojście , w przypadku migawki w czasie.

Wykluczenie antywirusowe

Skanowanie oprogramowania antywirusowego w plikach może spowodować błędy użycia pliku lub folderu podczas kompilacji lub wydania. Dodanie wykluczenia antywirusowego dla katalogu agenta i skonfigurowanie "folderu służbowego" może pomóc zidentyfikować oprogramowanie antywirusowe jako proces zakłócający.

MSBuild i /nodeReuse:false

Jeśli podczas kompilacji wywołasz program MSBuild, pamiętaj, aby przekazać argument /nodeReuse:false (krótki formularz /nr:false). W przeciwnym razie procesy MSBuild pozostaną uruchomione po zakończeniu kompilacji. Procesy pozostają przez pewien czas w oczekiwaniu na potencjalną kolejną kompilację.

Ta funkcja programu MSBuild może zakłócać próby usunięcia lub przeniesienia katalogu — z powodu konfliktu z katalogiem roboczym procesu MSBuild.

Zadania MSBuild i Visual Studio Build zostały już dodane /nr:false do argumentów przekazanych do programu MSBuild. Jeśli jednak wywołasz program MSBuild z poziomu własnego skryptu, musisz określić argument.

MSBuild i /maxcpucount:[n]

Domyślnie zadania kompilacji, takie jak MSBuild i Visual Studio Build, uruchamiają program MSBuild z przełącznikiem /m. W niektórych przypadkach może to powodować problemy, takie jak wiele problemów z dostępem do plików procesu.

Spróbuj dodać /m:1 argument do zadań kompilacji, aby wymusić uruchamianie tylko jednego procesu w programie MSBuild jednocześnie.

Problemy z używaniem plików mogą spowodować wykorzystanie funkcji współbieżnego procesu programu MSBuild. Nie określono argumentu /maxcpucount:[n] (skrócona forma /m:[n]) nakazuje programowi MSBuild używanie tylko jednego procesu. Jeśli używasz zadań MSBuild lub Visual Studio Build, może być konieczne określenie ciągu "/m:1", aby zastąpić argument "/m", który jest domyślnie dodawany.

Sporadyczne lub niespójne błędy programu MSBuild

Jeśli występują sporadyczne lub niespójne błędy programu MSBuild, spróbuj poinstruować program MSBuild, aby używał tylko jednego procesu. Sporadyczne lub niespójne błędy mogą wskazywać, że konfiguracja docelowa jest niezgodna z funkcją współbieżnego procesu programu MSBuild. Zobacz MSBuild i /maxcpucount:[n].

Proces przestaje odpowiadać

Proces przestaje odpowiadać przyczynom i krokach rozwiązywania problemów:

Oczekiwanie na dane wejściowe

Proces, który przestaje odpowiadać, może wskazywać, że proces oczekuje na dane wejściowe.

Uruchomienie agenta z poziomu wiersza polecenia interakcyjnej zalogowanej sesji może pomóc w ustaleniu, czy proces wyświetla monit o podanie danych wejściowych.

Uruchomienie agenta jako usługi może pomóc wyeliminować programy z monitowania o dane wejściowe. Na przykład na platformie .NET programy mogą polegać na wartości logicznej System.Environment.UserInteractive, aby określić, czy wyświetlić monit. Gdy agent jest uruchomiony jako usługa systemu Windows, wartość jest fałsz.

Zrzut procesu

Analizowanie zrzutu procesu może pomóc w zidentyfikowaniu, na co czeka zakleszany proces.

Projekt WiX

Kompilowanie projektu WiX po włączeniu niestandardowych rejestratorów MSBuild może spowodować zakleszczenie WiX czekanie na strumieniu danych wyjściowych. Dodanie dodatkowego argumentu /p:RunWixToolsOutOfProc=true MSBuild spowoduje obejście problemu.

Zakończenia wierszy dla różnych platform

Podczas uruchamiania potoków na wielu platformach czasami mogą wystąpić problemy z różnymi zakończeniami wierszy. Historycznie systemy Linux i macOS używały znaków linefeed (LF), podczas gdy system Windows używał powrotu karetki oraz kanału wiersza (CRLF). Usługa Git próbuje zrekompensować różnicę, automatycznie tworząc wiersze kończące się na LF w repozytorium, ale CRLF w katalogu roboczym w systemie Windows.

Większość narzędzi systemu Windows jest w porządku z zakończeniami tylko LF, a to automatyczne zachowanie może powodować więcej problemów niż rozwiązuje. Jeśli napotkasz problemy na podstawie zakończeń wierszy, zalecamy skonfigurowanie usługi Git tak, aby preferować język LF wszędzie. W tym celu dodaj .gitattributes plik do katalogu głównego repozytorium. W tym pliku dodaj następujący wiersz:

* text eol=lf

Zmienne z dołączonym cudzysłowem (pojedynczy cudzysłów)

Jeśli potok zawiera skrypt powłoki Bash, który ustawia zmienne przy użyciu ##vso polecenia, może zostać wyświetlony dodatkowy ' dołączany do wartości ustawionej zmiennej. Dzieje się tak z powodu interakcji z opcją set -x. Rozwiązaniem jest tymczasowe wyłączenie opcji set -x przed ustawieniem zmiennej. Składnia powłoki Bash umożliwiająca wykonanie tej operacji to set +x.

set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x

Dlaczego tak się dzieje?

Wiele skryptów powłoki Bash zawiera set -x polecenie ułatwiające debugowanie. Powłoka Bash prześle dokładnie to, jakie polecenie zostało wykonane, i echo go do stdout. Spowoduje to dwukrotne wyświetlanie ##vso polecenia przez agenta, a po raz drugi powłoka Bash doda ' znak na końcu.

Rozważmy na przykład ten potok:

steps:
- bash: |
    set -x
    echo ##vso[task.setvariable variable=MY_VAR]my_value

W przypadku elementu stdout agent będzie widzieć dwa wiersze:

##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'

Gdy agent zobaczy pierwszy wiersz, MY_VAR zostanie ustawiony na poprawną wartość "my_value". Jednak po wyświetleniu drugiego wiersza agent przetworzy wszystko na końcu wiersza. MY_VAR zostanie ustawiona wartość "my_value".

Biblioteki nie są instalowane dla aplikacji języka Python podczas wykonywania skryptu

Po wdrożeniu aplikacji języka Python w niektórych przypadkach potok ciągłej integracji/ciągłego wdrażania zostanie uruchomiony i kod zostanie pomyślnie wdrożony, ale plik requirements.txt , który jest odpowiedzialny za zainstalowanie wszystkich bibliotek zależności, nie jest wykonywany.

Aby zainstalować zależności, użyj skryptu po wdrożeniu w zadaniu wdrażania usługi App Service. W poniższym przykładzie pokazano polecenie, którego należy użyć w skry skryptie po wdrożeniu. Możesz zaktualizować skrypt dla danego scenariusza.

D:\home\python364x64\python.exe -m pip install -r requirements.txt

Aby rozwiązać problemy związane z połączeniami usług, zobacz Rozwiązywanie problemów z połączeniem z usługą.

Potok przestał słyszeć od agenta

Jeśli potok zakończy się niepowodzeniem z komunikatem, na przykład We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., sprawdź wykorzystanie zasobów agenta, aby sprawdzić, czy maszyna agenta kończy zasoby. Począwszy od przebiegu 228, dzienniki usługi Azure Pipelines zawierają metryki wykorzystania zasobów dla każdego kroku.

W przypadku korzystania z usług Azure DevOps Services można wyświetlić wykorzystanie zasobów w dziennikach, w tym użycie dysku, użycie pamięci i użycie procesora CPU, włączając pełne dzienniki. Po zakończeniu potoku wyszukaj wpisy w Agent environment resources dziennikach dla każdego kroku.

2024-02-28T17:41:15.1315148Z ##[debug]Agent environment resources - Disk: D:\ Available 12342.00 MB out of 14333.00 MB, Memory: Used 1907.00 MB out of 7167.00 MB, CPU: Usage 17.23%

Aby uzyskać informacje na temat przechwytywania dodatkowych dzienników wykorzystania zasobów, zobacz Przechwytywanie szczegółów wykorzystania zasobów.

Włączanie Eksplorator usługi Storage wdrażania zawartości statycznej, takiej jak .css i .js w statycznej witrynie internetowej z usługi Azure DevOps za pośrednictwem usługi Azure Pipelines

W tym scenariuszu możesz użyć zadania kopiowania plików platformy Azure, aby przekazać zawartość do witryny internetowej. Aby przekazać zawartość do kontenera internetowego, możesz użyć dowolnego z narzędzi opisanych w temacie Przekazywanie zawartości .

Następne kroki