Felsöka pipelinekörningar

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

Om pipelinekörningen inte kan slutföras använder du diagnostikinformationen och loggarna på sammanfattningssidan för pipelinekörningen för att felsöka problemet. Den här guiden innehåller instruktioner för att diagnostisera pipelinefel med hjälp av loggar, verktyg för felanalys och vanliga felsökningstekniker. Lär dig hur du identifierar rotorsaker och implementerar lösningar för att underlätta driften av dina rörledningar.

Tip

Du kan använda AI för att hjälpa till med den här uppgiften senare i den här artikeln, eller se Aktivera AI-hjälp med Azure DevOps MCP Server för att komma igång.

Skärmbild av sammanfattningssidan för pipelinekörning med diagnostikinformation.

Visa loggar

Välj felmeddelandet för att visa loggar för uppgiften som inte slutfördes.

Skärmbild av ett aktivitetsfelmeddelande på sammanfattningssidan för pipelinekörning.

Loggsidan visar det valda felet. I det här exemplet uppstår ett fel i cmd-line uppgiften, där echo kommandot anges som ech.

Skärmbild av diagnostikloggen för pipelinekörningen.

Du kan visa råloggen för uppgiften genom att välja Visa rålogg, och du kan söka i loggen med hjälp av Sök.

Skärmbild av loggvyalternativ i Azure DevOps.

Genomsök loggarna för den misslyckade uppgiften efter felinformation och ledtrådar om varför uppgiften misslyckas. Som standard genereras icke-verbose-loggar av en pipelinekörning. Om standardloggarna inte anger orsaken till problemet kan du få mer information genom att konfigurera utförliga loggar.

Sidan Felanalys

Felsökningshjälp finns på sidan Felanalys . Flytta musen över felinformationsraden och välj ikonen Visa analys .

Skärmbild av visningsanalysikonen på sammanfattningssidan för pipelinekörning.

Skärmbild av visningsanalysikonen för Azure DevOps Server.

Välj Visa agent för lokalt installerade agenter (eller Om värdbaserad agentbild för Microsoft-värdbaserade agenter) för att visa mer information om agenten som används för att köra pipelinen, och välj Visa logg för att se pipelinerapportens loggar.

Skärmbild av felanalyssidan i Azure DevOps portal.

Välj namnet på aktiviteten nedan Körningsinformation för att visa information om aktiviteten.

Skärmbild av aktivitetsinformation från felanalys.

I det här exemplet kan du se att det finns ett fel i Value på Script. Välj Om den här uppgiften för att visa dokumentationen för uppgiften.

Om problemet inte framgår av sammanfattningssidan för pipelinekörningen eller om du bläddrar i loggarna, kontrollera avsnittet Vanliga problem, och se avsnittet Granska loggar för att diagnostisera pipelineproblem för vägledning om hur du laddar ned fullständiga loggar som innehåller mer diagnostikinformation.

Vanliga problem

Uppgiftsinsikter för misslyckade pipelinekörningar

Azure DevOps innehåller inställningen Task Insights for Failed Pipeline Runs som när den är aktiverad ger popup-meddelanden om byggfel med en länk för att visa en rapport.

Skärmbild av aktivitetsinsiktsmått.

Om du vill konfigurera den här inställningen går du till Förhandsversionsfunktioner, söker efter Task Insights för misslyckade pipelinekörningar och väljer önskad inställning.

Skärmbild av aktivitetsinsikter för inställningen för misslyckade pipelinekörningar.

Meddelanden för misslyckade körningar

Azure DevOps innehåller inbyggda meddelanden för misslyckade pipelinekörningar. Så här aktiverar du meddelanden:

  1. Gå till Projektinställningar>Meddelanden för projektet.
  2. Välj vilken typ av meddelande du vill ta emot. Om du vill få ett meddelande varje gång en pipelinekörning misslyckas väljer du Ett bygge misslyckas.

Skärmbild av meddelanden i projektinställningar.

Den här pipelinen behöver behörighet att komma åt en resurs innan den här körningen kan fortsätta

Om pipelinen inte verkar starta, eller om du får ett felmeddelande som This pipeline needs permission to access a resource before this run can continue, kontrollerar du om pipelinen väntar på att en auktorisering ska köras av en resurs, till exempel en tjänstanslutning eller agentpool.

  1. Gå till pipelinen och starta en körning manuellt.
  2. Meddelandet Den här pipelinen behöver behörighet att komma åt en resurs innan den här körningen kan fortsätta visas. Välj Visa bredvid meddelandet.
  3. På skärmen Väntar på granskning väljer du Tillåt och på bekräftelseskärmen väljer du Tillåt igen.

Den här åtgärden lägger uttryckligen till pipelinen som en behörig användare av resursen.

Det finns två sätt att auktorisera pipelines för åtkomst till din agentpool.

Auktorisera specifika arbetsflöden

Du kan individuellt auktorisera specifika pipelines att köras i en agentpool genom att följa proceduren i föregående avsnitt när du får ett meddelande som This pipeline needs permission to access a resource before this run can continue.

Du kan också manuellt lägga till och ta bort pipelines från den auktoriserade listan genom att följa dessa steg. Den här proceduren utförs på projektnivå i din Azure DevOps organisation.

  1. I Azure DevOps går du till Projektinställningar, Agentpooler, väljer din egen värdbaserade pool och väljer Säkerhet.
  2. Välj + för att lägga till en pipeline till auktoriseringslistan.
  3. Välj X(Återkalla åtkomst) för att ta bort en pipeline från den auktoriserade listan.

Konfigurera öppen åtkomst

Med vissa resurser kan du konfigurera Öppen åtkomst så att varje ny pipelinedefinition inte kräver explicit auktorisering.

För att konfigurera öppen åtkomst krävs projektadministratörsbehörigheter .

Så här konfigurerar du Öppen åtkomst för agentpooler:

  1. I Azure DevOps går du till Projektinställningar, Agentpooler, väljer din egen värdbaserade pool och väljer Säkerhet.
  2. Välj Fler åtgärder, Öppna åtkomst för att aktivera öppen åtkomst och välj Öppna åtkomst igen för att bekräfta.
  3. Om du vill återkalla öppen åtkomst väljer du Begränsa behörighet.

Om du vill se om Öppna åtkomst är tillgängligt för andra resource-typer kan du läsa Hantera säkerhet i Azure-pipelines och söka efter Öppna åtkomst.

Mer information om Öppen åtkomst för agentpooler finns i Ange pipelinebehörigheter för en enskild agentpool och Pipeline-behörigheter.

Tidsgränsen för jobb uppnås

En pipeline kan köras under lång tid och sedan misslyckas på grund av tidsgränsen för jobbet. Tidsgränsen för jobb är nära beroende av vilken agent som används. Kostnadsfria Microsoft-värdbaserade agenter har en maximal timeout på 60 minuter per jobb för en privat lagringsplats och 360 minuter för en offentlig lagringsplats.

Om du vill öka den maximala tidsgränsen för ett jobb kan du välja något av följande.

  • Köp en agent som är värddriven av Microsoft som ger dig 360 minuter för alla uppgifter, oavsett lagringsplats.
  • Använd en lokalt installerad agent för att utesluta eventuella timeout-problem orsakade av agenten.

Läs mer om tidsgränsen för jobb.

Anmärkning

Om dina Microsoft-värdbaserade agentjobb överskrider tidsgränsen kontrollerar du att tidsgränsen för pipelinen är inställd på ett större värde än den maximala tidsgränsen för ett jobb. Mer information finns i Timeouter.

Problem med att ladda ned kod

Min pipeline misslyckas i ett utcheckningssteg

Om du använder ett checkout steg på en Azure-lagringsplatser Git-lagringsplats i din organisation som finns i ett annat projekt än din pipeline, kontrollera att inställningen Limit job authorization to current project är inaktiverad eller följ stegen i Scoped build identities för att säkerställa att pipelinen har åtkomst till lagringsplatsen.

När din pipeline inte kan komma åt lagringsplatsen på grund av begränsat omfång för jobbauktorisering får du felet Git fetch failed with exit code 128 och loggarna innehåller en post som liknar 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.

Om pipelinen misslyckas omedelbart med Could not find a project that corresponds with the repositorykontrollerar du att projektets och lagringsplatsens namn är korrekta i checkout steget eller lagringsplatsens resursdeklaration.

Problem med Team Foundation Version Control (TFVC)

Hämta källor som inte laddar ned vissa filer

Du kan se ett meddelande i loggen "Alla filer uppdaterade" från tf get kommandot . Kontrollera att den inbyggda tjänstidentiteten har behörighet att ladda ned källorna. Antingen måste identiteten Project Collection Build Service eller Project Build Service ha behörighet att ladda ned källorna, beroende på det valda auktoriseringsomfånget på fliken Allmänt i bygg-pipelinen. I webbgränssnittet för versionskontroll kan du bläddra bland projektfilerna på valfri nivå i mapphierarkin och kontrollera säkerhetsinställningarna.

Hämta källor via Team Foundation Proxy

Det enklaste sättet att konfigurera agenten att hämta källor via en Team Foundation-proxy är att ange miljövariabler TFSPROXY som pekar på TFVC-proxyservern för agentens körning som användare.

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

Min pipeline misslyckas i ett kommandoradssteg, till exempel MSBUILD

Avgöra ifall ett buildfel eller versionsfel beror på ett problem med Azure-pipelines-produkt (agent eller åtgärder) kan vara till hjälp. Versions- och versionsfel kan också bero på externa kommandon.

Kontrollera loggarna för den exakta kommandoraden som körs av den misslyckade uppgiften. Om du försöker köra kommandot lokalt från kommandoraden kan problemet återskapas. Det kan vara bra att köra kommandot lokalt från din egen dator och/eller logga in på datorn och köra kommandot som tjänstkonto.

Uppstår till exempel problemet under MSBuild-delen av bygg-pipelinen (till exempel använder du antingen MSBuild eller Visual Studio Build uppgift)? I så fall kan du prova att köra samma MSBuild-kommando på en lokal dator med samma argument. Om du kan återskapa problemet på en lokal dator är nästa steg att undersöka MSBuild-problemet .

Fillayout

Platsen för verktyg, bibliotek, rubriker och andra saker som behövs för en version kan skilja sig från den värdbaserade agenten än den lokala datorn. Om en version misslyckas eftersom den inte kan hitta någon av dessa filer kan du använda skripten nedan för att granska layouten på agenten. Detta kan hjälpa dig att spåra den saknade filen.

Skapa en ny YAML-pipeline på en tillfällig plats (till exempel en ny lagringsplats som skapats i syfte att felsöka). Som det är skrivet söker skriptet igenom kataloger på din sökväg. Du kan också redigera SEARCH_PATH= raden för att söka på andra platser.

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

Skillnader mellan lokal kommandotolk och agent

Tänk på att vissa skillnader gäller när du kör ett kommando på en lokal dator och när en version eller version körs på en agent. Om agenten är konfigurerad att köras som en tjänst på Linux, macOS eller Windows körs den inte i en interaktiv inloggad session. Utan en interaktiv inloggad session finns interaktion med användargränssnittet och andra begränsningar.

Fel med att filer eller mappar används

File or folder in use fel indikeras av felmeddelanden som:

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

Felsökningssteg:

Identifiera filer och mappar som används

På Windows kan verktyg som Process Monitor vara att samla in en spårning av filhändelser under en specifik katalog. Eller för en ögonblicksbild i tid kan verktyg som Process Explorer eller Handle användas.

Antivirusundantag

Antivirusprogram som skannar dina filer kan orsaka fil- eller mappanvändningsfel vid en bygg- eller releaseprocess, och byggen kan ta längre tid att bli klara. Att lägga till antivirusundantag för dina lokala agentkataloger och -processer kan hjälpa dig att lösa dessa problem.

Varning

Om du exkluderar filer eller processer från antivirusgenomsökning kan det göra enheten eller dina data mer sårbara. Utvärdera riskerna och uteslut endast sökvägar som du är säker på är säkra.

Processer som ska undantas:

  • Agent.Listener.exe
  • Agent.Worker.exe
  • AgentService.exe

Kataloger som ska undantas (och deras underkataloger):

  • Agentinstallationskatalogen (till exempel C:\agent eller /home/user/myagent)
  • Agentarbetsmappen: <agent_directory>\_work
  • Agentdiagnostikmappen: <agent_directory>\_diag
  • Skapa utdatamappar som konfigurerats för dina pipelines, till exempel mellanlagringskataloger, platser för artefaktborttagning och sökvägar för symbolpublicering
  • %ProgramFiles%\Microsoft Visual Studio\<VersionNumber>(Windows)
  • C:\Windows\Microsoft.NET\Framework\<VersionNumber>\Temporary ASP.NET Files(Windows)
  • C:\Windows\Microsoft.NET\Framework64\<VersionNumber>\Temporary ASP.NET Files(Windows)

Mer information finns i Antivirusgenomsökningsundantag.

MSBuild och /nodeReuse:false

Om du anropar MSBuild under bygget måste du skicka argumentet /nodeReuse:false (kort formulär /nr:false). Annars fortsätter MSBuild-processer att köras när bygget har slutförts. Processerna finns kvar under en tid i väntan på en potentiell efterföljande version.

Den här funktionen i MSBuild kan störa försök att ta bort eller flytta en katalog – på grund av en konflikt med arbetskatalogen för MSBuild-processerna.

MSBuild och Visual Studio Build-tasks lägger redan till /nr:false i argumenten som skickas till MSBuild. Men om du anropar MSBuild från ditt eget skript måste du ange argumentet.

MSBuild och /maxcpucount:[n]

Som standard kör build-uppgifter som MSBuild och Visual Studio Build MSBuild med växeln /m. I vissa fall kan detta orsaka problem, till exempel problem med åtkomst till flera processer.

Prova att lägga till argumentet i /m:1 dina bygguppgifter för att tvinga MSBuild att bara köra en process i taget.

Problem med filanvändning kan uppstå när funktionen samtidig process används i MSBuild. Om du inte anger argumentet /maxcpucount:[n] (kort formulär /m:[n]) instrueras MSBuild att endast använda en enda process. Om du använder MSBuild- eller Visual Studio Build-uppgifter kan du behöva ange "/m:1" för att åsidosätta argumentet "/m" som läggs till som standard.

Tillfälliga eller inkonsekventa MSBuild-fel

Om det uppstår tillfälliga eller inkonsekventa MSBuild-fel kan du prova att instruera MSBuild att endast använda en enda process. Tillfälliga eller inkonsekventa fel kan tyda på att målkonfigurationen inte är kompatibel med funktionen samtidig process i MSBuild. Se MSBuild och /maxcpucount:[n].

Processen slutar att svara

Processen slutar svara på orsaker och felsökningssteg:

Väntar på indata

En process som slutar svara kan tyda på att en process väntar på indata.

Att köra agenten från kommandoraden i en interaktiv inloggad session kan hjälpa till att identifiera om en process frågar med en dialogruta för indata.

Att köra agenten som en tjänst kan hjälpa till att eliminera program från att fråga efter indata. I .NET kan program till exempel förlita sig på System.Environment.UserInteractive Boolean för att avgöra om en uppmaning ska visas. När agenten körs som en Windows-tjänst är värdet falskt.

Processdump

Genom att analysera en dump av processen kan du identifiera vad en låst process väntar på.

WiX-projekt

Att skapa ett WiX-projekt när anpassade MSBuild-loggare är aktiverade kan leda till att WiX fastnar i ett dödläge i utdataströmmen. Att lägga till ytterligare MSBuild-argument /p:RunWixToolsOutOfProc=true fungerar kring problemet.

Radslut för flera plattformar

När du kör pipelines på flera plattformar kan du ibland stöta på problem relaterade till olika radslut. Tidigare använde Linux och macOS radmatningstecken (LF) medan Windows använde en vagnretur plus en radmatning (CRLF). Git försöker kompensera för skillnaden genom att automatiskt göra så att rader slutar med LF i lagringsutrymmet men med CRLF i arbetskatalogen på Windows.

De flesta Windows-verktyg fungerar bra med enbart LF-avslut, och denna automatiska funktion kan orsaka fler problem än den löser. Om du stöter på problem baserat på radslut rekommenderar vi att du konfigurerar Git för att föredra LF överallt. Det gör du genom att lägga till en .gitattributes fil i roten på lagringsplatsen. Lägg till följande rad i filen:

* text eol=lf

Variabler som har ' (enkelt citationstecken) tillagt

Om din pipeline innehåller ett Bash-skript som anger variabler med kommandot ##vso kan du se en annan ' som läggs till i värdet för den variabel som du anger. Detta beror på en interaktion med set -x. Lösningen är att inaktivera set -x tillfälligt innan du ställer in en variabel. Bash-syntaxen för att göra detta är set +x.

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

Varför inträffar det här?

Många Bash-skript innehåller set -x kommandot för att hjälpa till med felsökning. Bash spårar exakt vilket kommando som kördes och ekar det till stdout. Detta gör att agenten ser kommandot ##vso två gånger, och den andra gången har Bash lagt till tecknet ' i slutet.

Tänk till exempel på den här pipelinen:

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

På stdout ser agenten två rader:

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

När agenten ser den första raden kommer MY_VAR att ställas in på rätt värde, "my_value". Men när den ser den andra raden bearbetar agenten allt till slutet av raden. MY_VAR är inställt på "my_value'".

Bibliotek installeras inte för Python program när skriptet körs

När en Python-applikation distribueras körs i vissa fall en CI/CD-pipeline och koden distribueras framgångsrikt, men filen requirements.txt som ansvarar för att installera alla beroendebibliotek körs inte alls.

Om du vill installera beroendena använder du ett skript efter distributionen i App Service-distributionsuppgiften. I följande exempel visas det kommando som du måste använda i skriptet efter distributionen. Du kan uppdatera skriptet för ditt scenario.

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

Information om hur du felsöker problem som rör tjänstanslutningar finns i Felsökning av tjänstanslutningar. Mer information om hur du felsöker tjänstanslutningar med hjälp av arbetsbelastningsidentitet för autentisering finns i Felsöka anslutningar för arbetsbelastningsidentitetstjänsten.

Om en tidigare fungerande pipeline nu misslyckas när den försöker använda en tjänstanslutning kontrollerar du om Azure-pipelines inaktiverat anslutningen efter 100 dagars inaktivitet. Så här löser du problemet:

  1. Gå till Projektinställningar>Tjänstanslutningar.
  2. Öppna tjänstanslutningen som används av den misslyckade uppgiften.
  3. Granska flikarna Översikt och Användningshistorik för att bekräfta att anslutningen är inaktiverad och fastställa när den senast användes.
  4. Om du fortfarande behöver anslutningen väljer du Fler åtgärder>Aktivera.
  5. Kör pipelinen igen. Om autentiseringen fortfarande misslyckas kontrollerar du att den externa autentiseringsuppgiften eller den säkerhetskopierade identiteten fortfarande är giltig.

Granskningsloggen registrerar åtgärder för att inaktivera och aktivera.

Pipelinen slutade höra från agenten

Om din pipeline misslyckas med ett meddelande som We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.kontrollerar du agentens resursanvändning för att se om agentdatorn får slut på resurser. Från och med Sprint 228 innehåller Azure-pipelines loggar resursanvändningsmått för varje steg.

När du använder Azure DevOps Services kan du se resursutnyttjande i loggarna, inklusive diskanvändning, minnesanvändning och CPU-användning, genom att aktivera verbose-loggar. När pipelinen är avslutad, sök i loggarna efter Agent environment resources poster för varje steg.

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%

Information om hur du samlar in ytterligare resursanvändningsloggar finns i Samla in information om resursanvändning.

Aktivera Storage Explorer för att distribuera statiskt innehåll som .css och .js till en statisk webbplats från Azure DevOps via Azure-pipelines

I det här scenariot kan du använda aktiviteten Azure Filkopiering för att ladda upp innehåll till webbplatsen. Du kan använda något av de verktyg som beskrivs i Ladda upp innehåll för att ladda upp innehåll till webbcontainern.

Använda AI för att felsöka pipelinekörningar

Om du ansluter Azure DevOps MCP Server till AI-agenten i agentläge kan du använda frågor på naturligt språk för att undersöka misslyckade körningar, information om ytloggar och föreslå korrigeringar för vanliga pipelineproblem.

Task Exempelprompt
Diagnostisera en misslyckad körning Get the most recent failed run for the <Contoso-CI> pipeline and summarize the root cause from the logs
Hitta misslyckade aktivitetsloggar Show me the failing task in build <12345> and include the surrounding 50 lines of log output
Jämför med den senaste framgången Compare the failing run of <Contoso-CI> with the last successful run and tell me what changed
Undersök instabila tester List tests that failed intermittently across the last 10 runs of the <Contoso-CI> pipeline
Hantera behörighetsfel Build <12345> failed with a resource authorization error. Identify which resource needs approval and how to grant it
Analysera agentproblem Check the agent that ran build <12345> for capacity, capability, and connectivity problems
Undersök tidsgränsproblem Find jobs in the <Contoso-CI> pipeline that exceeded their timeout in the past week and show their durations
Identifiera vanliga felmönster Cluster the failure messages from the last 20 failed runs of <Contoso-CI> and rank the top causes
Föreslå YAML-korrigeringar Read the failing job in build <12345> and propose a YAML change that resolves the error
Kontrollera tjänstens anslutningshälsa List service connections used by <Contoso-CI> and flag any that are expired or about to expire

Anmärkning

Agentläget och MCP-servern använder naturligt språk, så du kan justera dessa frågor eller ställa uppföljningsfrågor för att förfina resultatet.

Relaterat innehåll

  • Last updated on