Problembehandlung für Pipelineausführungen

Azure DevOps Services | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018

In diesem Thema finden Sie allgemeine Anleitungen zur Problembehandlung. Spezifische Problembehandlung für .NET Core finden Sie unter .NET Core-Problembehandlung.

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Sie können die folgenden Problembehandlungsabschnitte verwenden, um Probleme mit Ihrer Pipeline zu diagnostizieren. Die meisten Pipelinefehler fallen in eine dieser Kategorien.

Pipeline löst nicht aus

Wenn eine Pipeline gar nicht gestartet wird, überprüfen Sie die folgenden häufig verwendeten Triggerprobleme.

Hinweis

Ein weiterer Grund, der nicht gestartet wird, ist, dass Ihre Organisation fünf Minuten nach der Anmeldung des letzten Benutzers von Azure DevOps ausgeht. Danach wird jede Ihrer Buildpipelinen einmal ausgeführt. Während Ihre Organisation z. B. ruhet:

  • Ein nachtweises Build von Code in Ihrer Organisation wird nur eine Nacht ausgeführt, bis sich jemand erneut anmeldet.
  • CI-Builds eines anderen Git-Repo werden nicht mehr ausgeführt, bis sich jemand erneut anmeldet.

Benutzeroberflächeneinstellungen außer Kraft setzen YAML-Triggereinstellung

YAML-Pipelines können ihre trigger und pr auslösenden Einstellungen in der Benutzeroberfläche der Pipelineeinstellungen außer Kraft setzen. Wenn Ihre trigger oder pr Trigger nicht ausgelöst werden scheinen, überprüfen Sie diese Einstellung. Wählen Sie beim Bearbeiten der Pipeline ... und dann Triggers aus.

Pipeline settings UI

Überprüfen Sie die YaML-Trigger aus dieser Einstellung für die Typen von Trigger (Fortlaufende Integration oder Pull-Anforderungsüberprüfung), die für Ihr Repo verfügbar sind.

Override YAML trigger from here.

Pull-Anforderungsauslöser werden mit Azure Repos nicht unterstützt.

Wenn Der pr Trigger nicht ausgelöst wird, und Sie Azure Repos verwenden, ist dies der Grund, dass pr Trigger für Azure Repos nicht unterstützt werden. In Azure Repos Git werden Verzweigungsrichtlinien verwendet, um die Pull-Anforderungs-Buildüberprüfung zu implementieren. Weitere Informationen finden Sie unter Branch-Richtlinie für die Pull-Anforderungsüberprüfung.

Verzweigungsfilter, die in CI- und PR-Triggern falsch konfiguriert sind

Wenn Sie einen YAML PR- oder CI-Trigger definieren, können Sie beide include und exclude Klauseln für Zweigen und Pfade angeben. Stellen Sie sicher, dass die include Klausel den Details Ihres Commits entspricht und dass die exclude Klausel sie nicht ausschließen.

Wichtig

Wenn Sie einen YAML-PR- oder CI-Trigger definieren, löst nur die für die Aufnahme explizit konfigurierten Zweigen eine Ausführung aus. Dies wird zuerst verarbeitet und dann aus der Liste ausgeschlossen. Wenn Sie einen Ausschluss angeben, aber keine Eingeschlossenen angeben, löst nichts aus. Weitere Informationen finden Sie unter PR und Trigger.

Wenn Sie einen YAML PR- oder CI-Trigger definieren, können Sie beide include und exclude Klauseln für Zweigen, Tags und Pfade angeben. Stellen Sie sicher, dass die include Klausel den Details Ihres Commits entspricht und dass die exclude Klausel sie nicht ausschließen. Weitere Informationen finden Sie unter PR und Trigger.

Hinweis

Wenn Sie eine exclude Klausel ohne include Klausel angeben, entspricht es der Angabe * in der include Klausel.

Geplante Zeitzonenkonvertierungen

YaML geplante Trigger werden mithilfe der UTC-Zeitzone festgelegt. Wenn Ihre geplanten Trigger nicht zum richtigen Zeitpunkt ausgelöst werden, bestätigen Sie die Konvertierungen zwischen UTC und Ihrer lokalen Zeitzone, wobei auch die Tageseinstellung berücksichtigt wird. Weitere Informationen finden Sie unter Geplanten Triggern.

Ui-Einstellungen außer Kraft setzen YAML geplante Trigger

Wenn Ihre YAML-Pipeline sowohl geplante YAML-Trigger als auch benutzeroberfläche definierte geplante Trigger enthält, werden nur die benutzeroberfläche definierten geplanten Trigger ausgeführt. Um die in Ihrer YAML-Pipeline definierten geplanten Trigger auszuführen, müssen Sie die geplanten Trigger entfernen, die in der Benutzeroberfläche der Pipelineeinstellungen definiert sind.

Um auf die Benutzeroberfläche der Pipelineeinstellungen aus einer YAML-Pipeline zuzugreifen, bearbeiten Sie Ihre Pipeline, wählen Sie ... und dann Trigger aus.

Pipeline settings UI

Entfernen Sie alle geplanten Trigger.

Delete scheduled triggers in the Pipeline settings UI.

Sobald alle geplanten Ui-Trigger entfernt wurden, muss ein Push vorgenommen werden, damit die geplanten YAML-Trigger ausgeführt werden. Weitere Informationen finden Sie unter Geplanten Triggern.

Pipelinewarteschlangen, aber nie einen Agent erhalten

Wenn Ihre Pipelinewarteschlangen jedoch nie einen Agent erhalten, überprüfen Sie die folgenden Elemente.

Hinweis

Die folgenden Szenarien nutzen keinen parallelen Auftrag:

  • Wenn Sie Releasepipelinen oder mehrstufige YAML-Pipelines verwenden, verbraucht eine Ausführung nur einen parallelen Auftrag, wenn sie aktiv in einer Phase bereitgestellt wird. Während die Veröffentlichung auf eine Genehmigung oder einen manuellen Eingriff wartet, nutzt sie keinen parallelen Auftrag.
  • Wenn Sie einen Serverauftrag ausführen oder mithilfe von Releasepipelinen in einer Bereitstellungsgruppe bereitstellen, verwenden Sie keine parallelen Aufträge.

Weitere Informationen: Verwenden eines parallelen Auftrags durch eine Pipeline, Hinzufügen von Vorabbereitstellungsgenehmigungen, Serveraufträgen, Bereitstellungsgruppen

Parallele Auftragsbeschränkungen – keine verfügbaren Agents oder Sie haben Ihre kostenlosen Grenzwerte getroffen

Wenn Sie derzeit andere Pipelines ausführen, haben Sie möglicherweise keine verbleibenden parallelen Aufträge, oder Sie haben möglicherweise Ihre freien Grenzwerte erreicht.

Um Ihre Grenzwerte zu überprüfen, navigieren Sie zu Project Einstellungen, Parallele Aufträge.

Pipelines concurrent jobs

Überprüfen Sie nach der Überprüfung der Grenzwerte die Übereinstimmung, um zu sehen, wie viele Aufträge derzeit ausgeführt werden und wie viele verfügbar sind.

Wenn Sie derzeit andere Pipelines ausführen, haben Sie möglicherweise keine verbleibenden parallelen Aufträge, oder Sie haben möglicherweise Ihre freien Grenzwerte erreicht.

Azure Key Vault hinter der Firewall kann von Azure DevOps nicht auf Azure Key Vault zugreifen.

Wenn Sie nicht auf Azure Key Vault aus Ihrer Pipeline zugreifen können, blockiert die Firewall möglicherweise die Azure DevOps Services Agent-IP-Adresse. Die in der wöchentlichen JSON-Datei veröffentlichten IP-Adressen müssen zulässig sein. Weitere Informationen finden Sie unter Microsoft gehostete Agents: Netzwerk.

Sie haben nicht genügend Übereinstimmungen

So überprüfen Sie, wie viel Übereinstimmung Sie haben:

  1. Um Ihre Grenzwerte zu überprüfen, navigieren Sie zu Project Einstellungen, Parallele Aufträge.

    Concurrent pipeline limits

    Sie können diese Seite auch erreichen, indem Sie zu https://dev.azure.com/{org}/_settings/buildqueue?_a=concurrentJobs, oder wählen Sie parallele Aufträge aus den Protokollen aus.

    Manage parallel jobs

  2. Bestimmen Sie, auf welchen Pool Sie die Übereinstimmung überprüfen möchten (von Microsoft gehostete oder selbst gehostete Pools), und wählen Sie " In-Progress-Aufträge anzeigen" aus.

  3. Sie sehen Text, der derzeit X/X-Aufträge ausführt. Wenn beide Zahlen identisch sind, warten Aufträge, bis derzeit ausgeführte Aufträge abgeschlossen sind.

    View in-progress jobs

    Sie können alle Aufträge anzeigen, einschließlich Warteschlangenaufträgen, indem Sie Agentpools aus den Project Einstellungen auswählen.

    View queued jobs

    In diesem Beispiel ist die gleichzeitige Auftragsgrenze eins, wobei ein Auftrag ausgeführt wird und eine Warteschlange nach oben ausgeführt wird. Wenn alle Agents mit dem Ausführen von Aufträgen beschäftigt sind, wie in diesem Beispiel, wird die folgende Meldung angezeigt, wenn zusätzliche Aufträge in der Warteschlange angezeigt werden: The agent request is not running because all potential agents are running other requests. Current position in queue: 1 In diesem Beispiel befindet sich der Auftrag als nächstes in der Warteschlange, sodass seine Position eine ist.

Ihr Auftrag kann auf die Genehmigung warten.

Ihre Pipeline wird möglicherweise nicht in die nächste Phase verschoben, da sie auf die Genehmigung wartet. Weitere Informationen finden Sie unter Definieren von Genehmigungen und Überprüfungen.

Alle verfügbaren Agents werden verwendet

Aufträge können warten, wenn alle Ihre Agents derzeit beschäftigt sind. So überprüfen Sie Ihre Agents:

  1. Navigieren Sie zu https://dev.azure.com/{org}/_settings/agentpools.

  2. Wählen Sie den Agentpool aus, um zu überprüfen, in diesem Beispiel FabrikamPool, und wählen Sie "Agents" aus.

    Agent status

    Auf dieser Seite werden alle derzeit online/offline verwendeten Agents angezeigt. Sie können auch zusätzliche Agents zum Pool aus dieser Seite hinzufügen.

Anforderungen, die nicht mit den Funktionen eines Agent übereinstimmen

Wenn Ihre Pipeline Anforderungen hat, die keine Funktionen Ihrer Agents erfüllen, wird Ihre Pipeline nicht gestartet. Falls einige Ihrer Agents über die gewünschten Funktionen verfügen und dafür derzeit andere Pipelines ausgeführt werden, wird Ihre Pipeline angehalten, bis einer dieser Agents verfügbar ist.

Verwenden Sie die Informationen unter Funktionen, um die Funktionen und Anforderungen zu überprüfen, die für Ihre Agents und Pipelines angegeben wurden.

Hinweis

Funktionen und Anforderungen werden in der Regel nur mit selbst gehosteten Agents verwendet. Wenn Ihre Pipeline Anforderungen hat, die nicht mit den Systemfunktionen des Agent übereinstimmen, sofern Sie die Agents nicht explizit mit übereinstimmenden Funktionen gekennzeichnet haben, erhalten Ihre Pipelines keinen Agent.

Probleme bei der TfS-Agent-Verbindung

Beim Testen der Agentverbindung (nur lokale TFS) schlägt die Konfiguration fehl.

Testing agent connection.
VS30063: You are not authorized to access http://<SERVER>:8080/tfs

Wenn der obige Fehler beim Konfigurieren des Agent empfangen wird, melden Sie sich bei Ihrem TFS-Computer an. Starten Sie den Internetinformationsdienste (IIS)-Manager. Stellen Sie sicher, dass die anonyme Authentifizierung aktiviert ist.

is TFS anonymous authentication enabled

Agent verlorene Kommunikation

Dieses Problem ist durch die Fehlermeldung gekennzeichnet:

The job has been abandoned because agent did not renew the lock. Ensure agent is running, not sleeping, and has not lost communication with the service.

Dieser Fehler kann darauf hinweisen, dass der Agent die Kommunikation mit dem Server für mehrere Minuten verloren hat. Überprüfen Sie folgendes, um Netzwerk- oder andere Unterbrechungen auf dem Agentcomputer auszuschließen:

  • Überprüfen Sie, ob automatische Updates deaktiviert sind. Ein Computerstart aus einem Update führt dazu, dass ein Build oder eine Version mit dem obigen Fehler fehlschlägt. Wenden Sie Updates in einer kontrollierten Weise an, um diese Art von Unterbrechung zu vermeiden. Bevor Sie den Agentcomputer neu starten, sollte der Agent zuerst auf der Poolverwaltungsseite deaktiviert sein und alle ausgeführten Buildvorgänge beenden.
  • Überprüfen Sie, ob die Schlafeinstellungen deaktiviert sind.
  • Wenn der Agent auf einem virtuellen Computer ausgeführt wird, vermeiden Sie eine Livemigration oder einen anderen VM-Wartungsvorgang, der die Integrität des Computers für mehrere Minuten stark beeinträchtigen kann.
  • Wenn der Agent auf einem virtuellen Computer ausgeführt wird, gelten die gleichen Empfehlungen für das Betriebssystemupdate und die Einstellungseinstellung für den Hostcomputer. Und auch alle anderen Wartungsvorgänge, die sich auf den Hostcomputer auswirken.
  • Leistungsüberwachungsprotokollierung oder andere Integritätsmetrische Protokollierung können dazu beitragen, diesen Fehlertyp zu korrelieren, um die Verfügbarkeit eingeschränkter Ressourcen auf dem Agentcomputer (Datenträger, Speicher, Seitendatei, Prozessor, Netzwerk) zu korrelieren.
  • Eine weitere Möglichkeit zum Korrelieren des Fehlers mit Netzwerkproblemen besteht darin, einen Server unbegrenzt zu pingen und die Ausgabe in eine Datei zusammen mit Zeitstempeln zu verlagern. Verwenden Sie ein gesundes Intervall, z. B. 20 oder 30 Sekunden. Wenn Sie Azure Pipelines verwenden, möchten Sie eine Internetdomäne anheften, z. B. bing.com. Wenn Sie einen lokalen TFS-Server verwenden, möchten Sie einen Server im gleichen Netzwerk pingen.
  • Überprüfen Sie, ob der Netzwerkdurchsatz des Computers angemessen ist. Sie können einen Onlinegeschwindigkeitstest durchführen, um den Durchsatz zu überprüfen.
  • Wenn Sie einen Proxy verwenden, überprüfen Sie, ob der Agent für die Verwendung Ihres Proxys konfiguriert ist. Weitere Informationen finden Sie im Thema zur Agentbereitstellung.

TFS-Auftrags-Agent wurde nicht gestartet

Dies kann durch eine Nachricht in der Webkonsole "Warten auf einen Agent, der angefordert werden soll" gekennzeichnet werden. Überprüfen Sie, ob der TFSJobAgent (Anzeigename: Visual Studio Team Foundation Background Job Agent) Windows Dienst gestartet wird.

Falsch konfigurierte Benachrichtigungs-URL (1.x Agent-Version)

Dies kann durch eine Nachricht in der Webkonsole "Warten auf Konsolenausgabe von einem Agent" gekennzeichnet werden, und der Prozess wird schließlich ausgedauert.

Eine falsch übereinstimmende Benachrichtigungs-URL kann dazu führen, dass der Mitarbeiter eine Verbindung mit dem Server nicht herstellen kann. Siehe Team Foundation-Verwaltungskonsole, Anwendungsebene. Der 1.x-Agent hört die Nachrichtenwarteschlange mithilfe der URL an, mit der sie konfiguriert wurde. Wenn jedoch eine Auftragsnachricht aus der Warteschlange abgerufen wird, verwendet der Arbeitsprozess die Benachrichtigungs-URL, um zurück an den Server zu kommunizieren.

Überprüfen des status Azure DevOps für einen Dienstverlust

Überprüfen Sie das Azure DevOps Dienststatusportal für alle Probleme, die zu einer Dienstbeschädigung führen können, z. B. erhöhte Warteschlangenzeit für Agents. Weitere Informationen finden Sie unter Azure DevOps Dienststatus.

Pipeline kann nicht abgeschlossen werden

Wenn Ihre Pipeline einen Agent erhält, aber nicht abgeschlossen ist, überprüfen Sie die folgenden allgemeinen Probleme. Wenn Ihr Problem nicht mit einem dieser Probleme übereinstimmt, finden Sie unter "Protokolle zum Diagnostizieren von Problemen".

Zeitüberschreitung des Auftrags

Eine Pipeline kann lange ausgeführt werden und dann aufgrund von Auftragszeit fehlschlagen. Auftragstimeout hängt eng vom verwendeten Agent ab. Kostenlose microsoft gehostete Agents verfügen über einen maximalen Timeout von 60 Minuten pro Auftrag für ein privates Repository und 360 Minuten für ein öffentliches Repository. Um das maximale Timeout für einen Auftrag zu erhöhen, können Sie sich für eine der folgenden Optionen entscheiden.

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

Erfahren Sie mehr über das Zeitout des Auftrags.

Hinweis

Wenn Ihre von Microsoft gehosteten Agent-Aufträge zeitgesteuerte Zeitüberschreitungen aufweisen, stellen Sie sicher, dass Sie keinen Pipeline-Timeout angegeben haben, der kleiner als der maximale Timeout für einen Auftrag ist. Informationen zum Überprüfen finden Sie unter Timeouts.

Probleme beim Herunterladen von Code

Meine Pipeline ist auf einem Auscheckschritt fehlgeschlagen.

Wenn Sie einen checkout Schritt in einem Azure Repos Git-Repository in Ihrer Organisation verwenden, das sich in einem anderen Projekt befindet als in Ihrer Pipeline, stellen Sie sicher, dass der Bereich "Auftragsberechtigung einschränken" auf aktuelle Projekteinstellung deaktiviert ist, oder führen Sie die Schritte in Bereichs-Buildidentitäten aus, um sicherzustellen, dass Ihre Pipeline Zugriff auf das Repository hat.

Wenn Ihre Pipeline aufgrund eingeschränkter Auftragsberechtigung nicht auf das Repository zugreifen kann, erhalten Sie den Fehler 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 fehlschlägt Could not find a project that corresponds with the repository, stellen Sie sicher, dass Ihr Projekt- und Repositoryname im Schritt oder in der checkout Repositoryressourcendeklaration richtig sind.

Probleme mit Team Foundation-Versionskontrolle (TFVC)

Abrufen von Quellen, die einige Dateien nicht herunterladen

Dies kann durch eine Nachricht im Protokoll "Alle Dateien auf dem neuesten Stand" vom Befehl tf get gekennzeichnet werden. Überprüfen Sie, ob die integrierte Dienstidentität über die Berechtigung zum Herunterladen der Quellen verfügt. Entweder der Identitäts-Project Sammlungs-Builddienst oder Project Builddienst benötigt die Berechtigung zum Herunterladen der Quellen, abhängig vom ausgewählten Autorisierungsbereich auf der Registerkarte "Allgemein" der Buildpipeline. In der Web-Benutzeroberfläche für die Versionskontrolle können Sie die Projektdateien auf jeder Ebene der Ordnerhierarchie durchsuchen und die Sicherheitseinstellungen überprüfen.

Abrufen von Quellen über den Team Foundation-Proxy

Die einfachste Möglichkeit, den Agent so zu konfigurieren, dass Quellen über einen Team Foundation-Proxy abgerufen werden können, ist eine Umgebungsvariable TFSPROXY , die auf den TFVC-Proxyserver für die Ausführung des Agent als Benutzer verweist.

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

Meine Pipeline ist auf einem Befehlszeilenschritt wie MSBUILD fehlschlägt.

Es ist hilfreich, zu einschränken, ob ein Build- oder Releasefehler das Ergebnis eines Azure Pipelines/TFS-Produktproblems (Agent oder Aufgaben) ist. Build- und Releasefehler können auch aus externen Befehlen resultieren.

Überprüfen Sie die Protokolle für die genaue Befehlszeile, die von der fehlgeschlagenen Aufgabe ausgeführt wird. Der Versuch, den Befehl lokal aus der Befehlszeile auszuführen, kann das Problem reproduzieren. Es kann hilfreich sein, den Befehl lokal von Ihrem eigenen Computer auszuführen, und/oder melden Sie sich an den Computer an, und führen Sie den Befehl als Dienstkonto aus.

Tritt beispielsweise das Problem während des MSBuild Teils Ihrer Buildpipeline auf (z. B. verwenden Sie entweder die MSBuild oder Visual Studio Buildaufgabe)? Versuchen Sie dann, denselben MSBuild Befehl auf einem lokalen Computer mit den gleichen Argumenten auszuführen. Wenn Sie das Problem auf einem lokalen Computer reproduzieren können, sollten Sie das MSBuild Problem untersuchen.

Dateilayout

Der Speicherort von Tools, Bibliotheken, Kopfzeilen und anderen Dingen, die für einen Build erforderlich sind, unterscheidet sich möglicherweise vom gehosteten Agent als vom lokalen Computer. Wenn ein Build fehlschlägt, da es keine dieser Dateien finden kann, können Sie die folgenden Skripts verwenden, um das Layout auf dem Agent zu überprüfen. Dies kann Ihnen helfen, die fehlende Datei nachzuverfolgen.

Erstellen Sie eine neue YAML-Pipeline an einem temporären Speicherort (z. B. ein neues Repo, das zum Zweck der Problembehandlung erstellt wurde). Wie geschrieben, durchsucht das Skript Verzeichnisse auf Ihrem Pfad. Sie können die SEARCH_PATH= Zeile optional bearbeiten, um andere Orte zu durchsuchen.

# 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 der lokalen Eingabeaufforderung und dem Agent

Beachten Sie, dass einige Unterschiede beim Ausführen eines Befehls auf einem lokalen Computer wirksam sind und wenn ein Build oder Release auf einem Agent ausgeführt wird. Wenn der Agent so konfiguriert ist, dass er als Dienst unter Linux, macOS oder Windows ausgeführt wird, wird er nicht in einer interaktiven angemeldeten Sitzung ausgeführt. Ohne eine interaktive angemeldete Sitzung sind ui-Interaktion und andere Einschränkungen vorhanden.

Datei oder Ordner in der Verwendung von Fehlern

Datei- oder Ordnerfehler werden häufig durch Fehlermeldungen wie z. B. folgende Fehlermeldungen angegeben:

  • 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 von Dateien und Ordnern, die verwendet werden

Auf Windows können Tools wie Process Monitor eine Ablaufverfolgung von Dateiereignissen unter einem bestimmten Verzeichnis erfassen. Oder für eine Momentaufnahme in der Zeit können Tools wie Prozess-Explorer oder Handle verwendet werden.

Anti-Virus-Ausschluss

Anti-Virus-Software beim Scannen Ihrer Dateien kann zu Fehlern bei der Verwendung von Dateien oder Ordnern während eines Build- oder Releasevorgangs führen. Das Hinzufügen eines Anti-Virus-Ausschlusss für Ihr Agent-Verzeichnis und konfigurierter "Arbeitsordner" kann dazu beitragen, Anti-Virus-Software als Störenprozess zu identifizieren.

MSBuild und /nodeReuse:false

Wenn Sie MSBuild während des Builds aufrufen, stellen Sie sicher, dass das Argument /nodeReuse:false (kurzes Formular/nr:false) übergeben wird. Andernfalls wird MSBuild Prozess(es) nach Abschluss des Buildvorgangs weiterhin ausgeführt. Der Prozess(es) bleibt für einige Zeit in Erwartung eines potenziellen nachfolgenden Builds.

Dieses Feature von MSBuild kann versuche stören, ein Verzeichnis zu löschen oder zu verschieben – aufgrund eines Konflikts mit dem Arbeitsverzeichnis des MSBuild Prozesses(es).

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

MSBuild und /maxcpucount:[n]

Standardmäßig werden die Buildaufgaben wie MSBuild und Visual Studio Build MSBuild mit dem /m Switch ausgeführt. In einigen Fällen kann dies Probleme verursachen, wie z. B. mehrere Prozessdateizugriffsprobleme.

Versuchen Sie, das /m:1 Argument zu Ihren Buildaufgaben hinzuzufügen, um MSBuild zu erzwingen, nur einen Prozess gleichzeitig auszuführen.

Datei-in-Use-Probleme können beim Nutzen des gleichzeitigen Prozessfeatures von MSBuild auftreten. Es wird nicht angegeben, dass das Argument /maxcpucount:[n] (kurzform/m:[n]) MSBuild nur einen einzigen Prozess verwendet. Wenn Sie die MSBuild- oder Visual Studio Buildaufgaben verwenden, müssen Sie möglicherweise "/m:1" angeben, um das Argument "/m" außer Kraft zu setzen, das standardmäßig hinzugefügt wird.

Unterbrechungen oder inkonsistente MSBuild Fehler

Wenn sie intermittierende oder inkonsistente MSBuild Fehler auftreten, versuchen Sie, MSBuild nur einen einzigen Prozess zu verwenden. Intermittierende oder inkonsistente Fehler können darauf hinweisen, dass ihre Zielkonfiguration nicht mit dem gleichzeitigen Prozessfeature von MSBuild kompatibel ist. Siehe MSBuild und /maxcpucount:[n].

Der Prozess reagiert nicht mehr

Der Prozess reagiert nicht mehr auf Ursachen und Problembehandlungsschritte:

Warten auf Eingabe

Ein Prozess, der nicht mehr reagiert, kann darauf hinweisen, dass ein Prozess auf die Eingabe wartet.

Das Ausführen des Agents aus der Befehlszeile einer interaktiven angemeldeten Sitzung kann dazu beitragen, zu ermitteln, ob ein Prozess mit einem Dialogfeld zur Eingabe aufgefordert wird.

Das Ausführen des Agent als Dienst kann dazu beitragen, Programme zu beseitigen, die zur Eingabe aufgefordert werden. In .NET können Programme z. B. auf system.Environment.UserInteractive Boolean angewiesen sein, um zu ermitteln, ob sie aufgefordert werden sollen. Beim Ausführen als Windows-Dienst ist der Wert falsch.

Prozessabbild

Die Analyse eines Abbilds des Prozesses kann dazu beitragen, zu identifizieren, auf was ein totsperrter Prozess wartet.

WiX-Projekt

Das Erstellen eines WiX-Projekts, wenn benutzerdefinierte MSBuild Logger aktiviert sind, kann dazu führen, dass WiX auf den Ausgabedatenstrom wartet. Durch das Hinzufügen des zusätzlichen MSBuild-Arguments /p:RunWixToolsOutOfProc=true wird das Problem behoben.

Zeilenende für mehrere Plattformen

Wenn Sie Pipelines auf mehreren Plattformen ausführen, können Sie manchmal Probleme mit verschiedenen Linienende haben. Früher verwendet Linux und macOS Linefeed (LF)-Zeichen, während Windows eine Wagenrückgabe und eine Linienfeed (CRLF) verwendet haben. Git versucht, den Unterschied zu ausgleichen, indem Zeilen automatisch in LF im Repo enden, CRLF jedoch im Arbeitsverzeichnis auf Windows.

Die meisten Windows Tools sind mit nur LF-Enden fein, und dieses automatische Verhalten kann mehr Probleme verursachen als es löst. Wenn Probleme aufgrund von Zeilenende auftreten, empfehlen wir Ihnen, Git überall zu bevorzugen. Fügen Sie dazu eine .gitattributes Datei zum Stamm Ihres Repositorys hinzu. Fügen Sie in dieser Datei die folgende Zeile hinzu:

* text eol=lf

Variablen mit anfügender Anführungszeichen (einzelne Anführungszeichen)

Wenn Ihre Pipeline ein Bash-Skript enthält, das Variablen mithilfe des ##vso Befehls festlegt, wird möglicherweise ein zusätzlicher ' Anfügen an den Wert der von Ihnen festgelegten Variablen angezeigt. Dies tritt aufgrund einer Interaktion mit set -x. Die Lösung besteht darin, eine Variable vorübergehend zu deaktivieren set -x . Die Bash-Syntax für die Vorgehensweise 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 umfassen den set -x Befehl zum Debuggen. Bash verfolgt genau, welche Befehle ausgeführt wurden, und echot es an stdout. Dadurch wird der Agent dazu führen, dass der Befehl zweimal angezeigt ##vso wird, und das zweite Mal hat Bash das ' Zeichen zum Ende hinzugefügt.

Ziehen Sie beispielsweise diese Pipeline in Betracht:

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

Bei stdout wird der Agent zwei Zeilen sehen:

##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 auf den richtigen Wert festgelegt, MY_VAR "my_value". Wenn die zweite Zeile angezeigt wird, verarbeitet der Agent jedoch alles am Ende der Zeile. MY_VAR wird auf "my_value'" festgelegt.

Bibliotheken werden nicht für Python-Anwendung installiert, wenn Skript ausgeführt wird

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

Verwenden Sie zum Installieren der Abhängigkeiten ein Postbereitstellungsskript in der App Service Bereitstellungsaufgabe. Das folgende Beispiel zeigt den Befehl, den Sie im Skript für die Postbereitstellung verwenden müssen. Sie können das Skript für Ihr Szenario aktualisieren.

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

Informationen zur Problembehandlung bei Dienstverbindungen finden Sie unter " Dienstverbindungsbehandlung".

Aktivieren Sie Storage-Explorer die Bereitstellung statischer Inhalte wie CSS und .js einer statischen Website von Azure DevOps über Azure Pipelines

In diesem Szenario können Sie die Azure-Dateikopie-Aufgabe verwenden, um Inhalte auf die Website hochzuladen. Sie können alle tools verwenden, die im Hochladen von Inhalten beschrieben sind, um Inhalte im Webcontainer hochzuladen.

Abrufen von Protokollen zur Diagnose von Problemen

Wenn keine der vorherigen Vorschläge ihrem Problem entspricht, können Sie die Informationen in den Protokollen verwenden, um Ihre fehlgeschlagene Pipeline zu diagnostizieren.

Beginnen Sie mit der Suche nach den Protokollen in Ihrem abgeschlossenen Build oder Ihrer Version. Sie können Protokolle anzeigen, indem Sie zur Zusammenfassung der Pipelineausführung navigieren und dann den Auftrag und die Aufgabe auswählen. Wenn eine bestimmte Aufgabe fehlschlägt, überprüfen Sie die Protokolle dafür.

Zusätzlich zum Anzeigen von Protokollen in der Pipeline-Buildzusammenfassung können Sie vollständige Protokolle herunterladen, die zusätzliche Diagnoseinformationen enthalten, und Sie können ausführlichere Protokolle konfigurieren, um Ihre Problembehandlung zu unterstützen.

Ausführliche Anleitungen zum Konfigurieren und Verwenden von Protokollen finden Sie unter Überprüfen von Protokollen zum Diagnostizieren von Pipelineproblemen.

Ich benötige weitere Hilfe. Ich habe einen Fehler gefunden. Ich habe einen Vorschlag. Wo gehe ich?

Abrufen von Abonnements, Abrechnungen und technischem Support

Melden Sie Probleme, oder senden Sie Feedback zu Entwicklercommunity.

Wir begrüßen Ihre Vorschläge: