Problembehandlung für Pipelineausführungen

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

Wenn die Pipelineausführung nicht abgeschlossen werden kann, können Sie die Diagnoseinformationen und Protokolle der Seite mit der Zusammenfassung der Pipelineausführung verwenden, um das Problem zu beheben.

Anzeigen von Protokollen

Wählen Sie die Fehlermeldung aus, um die Protokolle für die Aufgabe anzuzeigen, die nicht abgeschlossen werden konnte.

Die Protokollseite wird angezeigt, wobei der Fehler ausgewählt ist. In diesem Beispiel gibt es einen Fehler in der Aufgabe cmd-line, in der der Befehl echo als ech eingegeben ist.

Sie können das unformatierte Protokoll für die Aufgabe anzeigen, indem Sie Unformatiertes Protokoll anzeigen auswählen und das Protokoll mithilfe von Suchen durchsuchen.

Überprüfen Sie die Protokolle der fehlerhaften Aufgabe auf Fehlerinformationen und Hinweise dazu, warum die Aufgabe fehlschlägt. Standardmäßig werden nicht ausführliche Protokolle von einer Pipelineausführung generiert. Wenn die Standardprotokolle nicht auf die Ursache des Problems hinweisen, können Sie weitere Informationen erhalten, indem Sie ausführliche Protokolle konfigurieren.

Wenn das Problem auf der Zusammenfassungsseite der Pipelineausführung oder beim Durchsuchen der Protokolle nicht ersichtlich ist, überprüfen Sie den folgenden Abschnitt Häufige Probleme, und lesen Sie Protokolle überprüfen, um Pipelineprobleme zu diagnostizieren, um Informationen zum Herunterladen vollständiger Protokolle zu erhalten, die zusätzliche Diagnoseinformationen enthalten.

Häufige Probleme

• Auftragstimeout
• Probleme beim Herunterladen von Code
• Fehler in meiner Pipeline bei einem Befehlszeilenschritt wie MSBUILD
• Fehler „Datei oder Ordner in Verwendung
• Zeitweilige oder inkonsistente MSBuild-Fehler
• Prozess reagiert nicht mehr
• Zeilenenden für mehrere Plattformen
• Variablen, an die ein einfaches Anführungszeichen (') angefügt wurde
• Probleme mit Dienstverbindungen
• Die Pipeline hat den Kontakt zum Agent verloren

Auftragstimeout

Eine Pipeline kann lange ausgeführt werden und dann aufgrund eines Auftragstimeouts fehlschlagen. Das Zeitlimit für Aufträge hängt stark vom verwendeten Agent ab. Kostenlose von Microsoft gehostete Agents haben ein maximales Timeout von 60 Minuten pro Auftrag für ein privates Repository und von 360 Minuten für eine öffentliches Repository. Um das maximale Timeout für einen Auftrag zu erhöhen, können Sie eine der folgenden Optionen wählen.

• Kaufen Sie einen von Microsoft gehosteten Agent, der Ihnen unabhängig vom verwendeten Repository für alle Aufträge 360 Minuten gewährt.
• Verwenden Sie einen selbstgehosteten Agent, um Timeoutprobleme aufgrund des Agents auszuschließen.

Erfahren Sie mehr über das Timeout von Aufträgen.

Probleme beim Herunterladen von Code

• Meine Pipeline schlägt bei einem Auscheckschritt fehl
• Probleme mit Team Foundation-Versionskontrolle (TFVC)

Meine Pipeline schlägt bei einem Auscheckschritt fehl

Wenn Sie einen checkout-Schritt für ein Git-Repository in Azure Repos in Ihrer Organisation ausführen, das sich in einem anderen Projekt als Ihre Pipeline befindet, stellen Sie sicher, dass die Einstellung Autorisierungsbereich für Auftrag auf aktuelles Projekt begrenzen deaktiviert ist. Oder folgen Sie den Schritten in Bereichsbezogene Buildidentitäten, um sicherzustellen, dass Ihre Pipeline Zugriff auf das Repository hat.

Wenn Ihre Pipeline aufgrund des begrenzten Auftragsautorisierungsbereichs nicht auf das Repository zugreifen kann, erhalten Sie die Fehlermeldung Git fetch failed with exit code 128, und Ihre Protokolle enthalten einen Eintrag ähnlich wie 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.

Wenn ihre Pipeline sofort mit Could not find a project that corresponds with the repositoryfehlschlägt, stellen Sie sicher, dass Ihr Projekt- und Repositoryname im checkout-Schritt oder in der Repositoryressourcendeklaration stimmen.

Probleme mit Team Foundation-Versionskontrolle (TFVC)

• Beim Abrufen von Quellen werden einige Dateien nicht herunterladen
• Abrufen von Quellen über Team Foundation-Proxy

Beim Abrufen von Quellen werden einige Dateien nicht herunterladen

Dies kann durch die Meldung „Alle Dateien sind auf dem neuesten Stand“ im Protokoll des tf get-Befehls signalisiert werden. Verifizieren Sie, ob die integrierte Dienstidentität über die Berechtigung zum Herunterladen der Quellen verfügt. Entweder die Identität Builddienst für Projektsammlung oder Builddienst für Projekt benötigt abhängig vom ausgewählten Autorisierungsbereich auf der Registerkarte „Allgemein“ der Buildpipeline die Berechtigung zum Herunterladen der Quellen. Auf der Web-Benutzeroberfläche der Versionskontrolle können Sie die Projektdateien auf jeder Ebene der Ordnerhierarchie durchsuchen und die Sicherheitseinstellungen überprüfen.

Abrufen von Quellen über Team Foundation-Proxy

Die einfachste Möglichkeit zum Konfigurieren des Agents zum Abrufen von Quellen über einen Team Foundation-Proxy besteht darin, die Umgebungsvariable TFSPROXY festzulegen, die auf den TFVC-Proxyserver für die Ausführung des Agents als Benutzer zeigt.

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

Mac OS/Linux:

    export TFSPROXY=http://tfvcproxy:8081

Fehler in meiner Pipeline bei einem Befehlszeilenschritt wie MSBUILD

Es ist hilfreich einzugrenzen, ob ein Build- oder Releasefehler das Ergebnis eines Azure Pipelines-/TFS-Produktproblems (Agent oder Aufgaben) ist. Build- und Releasefehler können auch auf externe Befehle zurückzuführen sein.

Überprüfen Sie die Protokolle auf die genaue Befehlszeile, die von der fehlerhaften Aufgabe ausgeführt wird. Wenn Sie versuchen, den Befehl lokal über die Befehlszeile auszuführen, kann das Problem reproduziert werden. Es kann hilfreich sein, den Befehl lokal auf Ihrem eigenen Computer auszuführen und/oder sich beim Computer anzumelden und den Befehl über das Dienstkonto auszuführen.

Tritt das Problem beispielsweise während des MSBuild-Teils Ihrer Buildpipeline auf (verwenden Sie beispielsweise entweder die Aufgabe MSBuild oder Visual Studio-Build?) Falls ja, versuchen Sie, denselben MSBuild-Befehl auf einem lokalen Computer mit den gleichen Argumenten auszuführen. Wenn Sie das Problem auf einem lokalen Computer reproduzieren können, müssen Sie als Nächstes das MSBuild-Problem untersuchen.

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

Unterschiede zwischen lokaler Eingabeaufforderung und Agent

Beachten Sie, dass einige Unterschiede bestehen, wenn ein Befehl auf einem lokalen Computer ausgeführt wird und wenn ein Build oder eine Version auf einem Agent ausgeführt wird. Wenn der Agent unter Linux, macOS oder Windows für die Ausführung als Dienst konfiguriert ist, wird er nicht innerhalb einer interaktiven angemeldeten Sitzung ausgeführt. Ohne eine interaktive angemeldete Sitzung bestehen u. a. Einschränkungen bei der Interaktion mit der Benutzeroberfläche.

Fehler „Datei oder Ordner in Verwendung

Fehler des Typs File or folder in use werden häufig von Fehlermeldungen begleitet, wie z. B.:

• 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 [...]

Schritte zur Problembehandlung:

• Erkennen verwendeter Dateien und Ordner
• Ausschluss von Virenschutz
• MSBuild und /nodeReuse:false
• MSBuild und /maxcpucount:[n]

Erkennen verwendeter Dateien und Ordner

Unter Windows können Tools wie Prozessmonitor eine Ablaufverfolgung von Dateiereignissen in einem bestimmten Verzeichnis erfassen. Oder für eine zeitpunktbezogene Momentaufnahme können Tools wie Prozess-Explorer oder Handle verwendet werden.

Ausschluss von Virenschutz

Die Überprüfung ihrer Dateien durch Virenschutzsoftware kann während eines Builds oder Releases zu Datei- oder Ordnerfehlern führen. Das Hinzufügen eines Ausschlusses von Virenschutz für Ihr Agent-Verzeichnis und den konfigurierten „Arbeitsordner“ kann dazu beitragen, Virenschutzsoftware als störenden Prozess zu identifizieren.

MSBuild und /nodeReuse:false

Wenn Sie MSBuild während des Builds aufrufen, stellen Sie sicher, dass Sie das Argument /nodeReuse:false (Kurzform /nr:false) übergeben. Andernfalls werden MSBuild-Prozesse nach Abschluss des Builds fortgesetzt. Die Prozesse bleiben für einige Zeit in Erwartung eines potenziell nachfolgenden Builds aktiv.

Dieses Feature von MSBuild kann Versuche, ein Verzeichnis zu löschen oder zu verschieben, beeinträchtigen, und zwar aufgrund eines Konflikts mit dem Arbeitsverzeichnis der MSBuild-Prozesse.

Die MSBuild- und Visual Studio-Buildaufgaben fügen bereits /nr:false zu den an MSBuild übergebenen Argumenten hinzu. Wenn Sie MSBuild jedoch in Ihrem eigenen Skript aufrufen, müssen Sie das Argument angeben.

MSBuild und /maxcpucount:[n]

Standardmäßig führen die Buildaufgaben wie MSBuild und Visual Studio-Build MSBuild mit dem Schalter /m aus. In einigen Fällen kann dies Probleme verursachen, z. B. beim Zugriff auf mehrere Prozessdateien.

Versuchen Sie, das Argument /m:1 Ihren Buildaufgaben hinzuzufügen, um MSBuild zu zwingen, dass nur jeweils ein Prozess ausgeführt wird.

Es kann zu Problemen mit in Verwendung befindlichen Dateien kommen, wenn Sie das Feature „Gleichzeitige Prozesse“ von MSBuild nutzen. Wenn Sie das Argument /maxcpucount:[n] (Kurzform /m:[n]) nicht angeben, wird MSBuild angewiesen, nur einen einzelnen Prozess zu verarbeiten. Wenn Sie die MSBuild- oder Visual Studio-Buildaufgaben verwenden, müssen Sie möglicherweise „/m:1“ angeben, um das standardmäßig hinzugefügte Argument „/m“ außer Kraft zu setzen.

Zeitweilige oder inkonsistente MSBuild-Fehler

Wenn zeitweilige oder inkonsistente MSBuild-Fehler auftreten, weisen Sie MSBuild an, nur einen einzelnen Prozess zu verwenden. Zeitweilige oder inkonsistente Fehler können darauf hindeuten, dass Ihre Zielkonfiguration mit dem Feature „Gleichzeitige Prozesse“ von MSBuild nicht kompatibel ist. Weitere Informationen finden Sie unter MSBuild und /maxcpucount:[n].

Prozess reagiert nicht mehr

Ursachen dafür, dass ein Prozess nicht mehr reagiert, und Schritte zur Problembehandlung:

• Warten auf Eingabe
• Speicherabbild des Prozesses
• WiX-Projekt

Warten auf Eingabe

Ein nicht mehr reagierender Prozess kann darauf hindeuten, dass ein Prozess auf Eingaben wartet.

Das Ausführen des Agents über die Befehlszeile einer interaktiv angemeldeten Sitzung kann helfen zu erkennen, ob ein Prozess in einem Dialogfeld zur Eingabe auffordert.

Wenn Sie den Agent als Dienst ausführen, können Sie verhindern, dass Programme zu Eingaben auffordern. In .NET können Programme beispielsweise auf den booleschen Wert System.Environment.UserInteractive zurückgreifen, um zu bestimmen, ob eine Eingabeaufforderung erfolgen soll. Wenn der Agent als Windows-Dienst ausgeführt wird, ist der Wert FALSE.

Speicherabbild des Prozesses

Die Analyse eines Speicherabbilds des Prozesses kann helfen zu ermitteln, worauf ein Prozess mit Deadlock wartet.

WiX-Projekt

Die Erstellung eines WiX-Projekts, wenn benutzerdefinierte MSBuild-Protokollierungen aktiviert sind, kann dazu führen, dass WiX beim Warten auf den Ausgabedatenstrom auf ein Deadlock stößt. Durch Hinzufügen des zusätzlichen MSBuild-Arguments /p:RunWixToolsOutOfProc=true kann das Problem umgangen werden.

Zeilenenden für mehrere Plattformen

Wenn Sie Pipelines auf mehreren Plattformen ausführen, können mitunter Probleme mit unterschiedlichen Zeilenendungen auftreten. In der Vergangenheit wurden unter Linux und macOS Zeilenvorschubzeichen (LF) verwendet, während unter Windows ein Wagenrücklauf plus Zeilenvorschub (CRLF) verwendet wurde. Git versucht, diesen Unterschied zu kompensieren, indem es Zeilen im Repository automatisch mit LF enden lässt, im Arbeitsverzeichnis unter Windows jedoch mit CRLF.

Die meisten Windows-Tools kommen mit reinen LF-Endungen zurecht, und dieses automatische Verhalten kann mehr Probleme verursachen, als es löst. Wenn aufgrund von Zeilenendungen Probleme auftreten, empfehlen wir Ihnen, Git so zu konfigurieren, dass LF überall bevorzugt wird. Fügen Sie dazu dem Stammverzeichnis Ihres Repositorys die Datei .gitattributes hinzu. Fügen Sie dieser Datei die folgende Zeile hinzu:

* text eol=lf

Variablen, an die ein einfaches Anführungszeichen (') angefügt wurde

Wenn Ihre Pipeline ein Bash-Skript enthält, das Variablen mithilfe des Befehls ##vso festlegt, wird möglicherweise eine zusätzliche ' an den Wert der von Ihnen festgelegten Variablen angefügt. Dies geschieht aufgrund einer Interaktion mit set -x. Die Lösung besteht darin, set -x vorübergehend zu deaktivieren, bevor eine Variable gesetzt wird. Die Bash-Syntax dafür ist set +x.

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

Was ist dafür die Ursache?

Viele Bash-Skripts enthalten den set -x-Befehl zur Unterstützung des Debuggens. Bash verfolgt genau, welcher Befehl ausgeführt wurde, und gibt ihn in stdout aus. Dies führt dazu, dass der Agent den ##vso-Befehl zweimal sieht, wobei Bash beim zweiten Mal das Zeichen ' an das Ende angefügt hat.

Betrachten Sie beispielsweise diese Pipeline:

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

In stdout werden dem Agent zwei Zeilen angezeigt:

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

Wenn der Agent die erste Zeile sieht, wird MY_VAR auf den richtigen Wert (my_value) festgelegt. Wenn ihm jedoch die zweite Zeile angezeigt wird, verarbeitet der Agent alles bis zum Ende der Zeile. MY_VAR wird auf „my_value“ festgelegt.

Bei Ausführung des Skripts werden keine Bibliotheken für die Python-Anwendung installiert

Bei der Bereitstellung einer Python-Anwendung wird in manchen Fällen eine CI/CD-Pipeline ausgeführt und der Code erfolgreich bereitgestellt, aber die Datei requirements.txt, die für die Installation aller Abhängigkeitsbibliotheken zuständig ist, wird nicht ausgeführt.

Um die Abhängigkeiten zu installieren, verwenden Sie in der App Service-Bereitstellungsaufgabe ein Skript nach der Bereitstellung. Das folgende Beispiel zeigt den Befehl, den Sie im Skript nach der Bereitstellung verwenden müssen. Sie können das Skript für Ihr Szenario aktualisieren.

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

Probleme mit Dienstverbindungen

Informationen zur Behandlung von Problemen im Zusammenhang mit Dienstverbindungen finden Sie unter Problembehandlung für Dienstverbindungen.

Die Pipeline hat den Kontakt zum Agent verloren

Wenn Ihre Pipeline eine Fehlermeldung ähnlich der folgenden ausgibt: We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., überprüfen Sie in der Ressourcenverwendung des Agents, ob die Ressourcen des Agent-Computers ausgeschöpft sind. Ab Sprint 228, enthalten Azure Pipelines-Protokolle für jeden Schritt Kennzahlen zur Ressourcenverwendung.

Wenn Sie Azure DevOps Services verwenden, können Sie die Ressourcenauslastung in den Protokollen sehen, einschließlich Datenträgernutzung, Speicherauslastung und CPU-Auslastung, indem Sie ausführliche Protokolle aktivieren. Wenn die Pipeline abgeschlossen ist, durchsuchen Sie die Protokolle nach Agent environment resources Einträgen für jeden Schritt.

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%

Informationen zum Erfassen zusätzlicher Ressourcenverwendungsprotokolle finden Sie unter Erfassen von Informationen zur Ressourcenverwendung.

Aktivieren von Storage-Explorer zum Bereitstellen statischer Inhalte wie CSS- und JS-Dateien auf einer statischen Website aus Azure DevOps über Azure Pipelines

In diesem Szenario können Sie den Azure-Dateikopiervorgang verwenden, um Inhalte auf die Website hochzuladen. Sie können mit einem der unter Hochladen von Inhalten beschriebenen Tools Inhalte in den Webcontainer hochladen.

Nächste Schritte

• Überprüfen von Protokollen