Felsöka pipelinekörningar

  • Artikel

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

Om pipelinekörningen inte kan slutföras kan du använda diagnostikinformationen och loggarna som tillhandahålls av sammanfattningssidan för pipelinekörningen för att felsöka problemet.

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

Visa loggar

Välj felmeddelandet för att visa loggarna för uppgiften som inte kunde slutföras.

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

Loggsidan visas med felet valt. 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 loggvisningsalternativ 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 Visa logg för att visa pipelinekörningsloggarna.

Skärmbild av sidan för felanalys i Azure DevOps-portalen.

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 .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 läser du avsnittet Vanliga problem och läser Granska loggar för att diagnostisera pipelineproblem för information om hur du laddar ned fullständiga loggar som innehåller ytterligare diagnostikinformation.

Vanliga problem

Uppgiftsinsikter för misslyckade pipelinekörningar

Azure DevOps tillhandahåller en task insights för misslyckade pipelinekörningar , 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 misslyckade pipelinekörningar.

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 Microsoft-värdbaserad agent som ger dig 360 minuter för alla jobb, oavsett vilken lagringsplats som används
  • Använd en lokalt installerad agent för att utesluta eventuella timeout-problem på grund av agenten

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

Kommentar

Om dina Microsoft-värdbaserade agentjobb överskrider tidsgränsen kontrollerar du att du inte har angett en tidsgräns för pipeline som är mindre ä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 Repos Git-lagringsplats i din organisation som finns i ett annat projekt än din pipeline kontrollerar du att begränsa jobbauktoriseringsomfånget till den aktuella projektinställningen är inaktiverat eller följer stegen i Begränsade byggidentiteter för att säkerställa att din pipeline 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

Detta kan kännetecknas av 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övariabeln 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

Det är bra att begränsa om ett bygg- eller versionsfel beror på ett Azure Pipelines/TFS-produktproblem (agent eller uppgifter). 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.

Inträffar till exempel problemet under MSBuild-delen av bygg-pipelinen (till exempel använder du antingen uppgiften MSBuild eller Visual Studio Build )? 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 (t.ex. 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 för att köras som en tjänst i 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 ofta 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

I 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 söker igenom dina filer kan orsaka fil- eller mappanvändningsfel under en version eller utgåva. Att lägga till ett antivirusundantag för agentkatalogen och konfigurerad "arbetsmapp" kan hjälpa till att identifiera antivirusprogram som störande process.

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 i MSBuild-processen(es).

Uppgifterna MSBuild och Visual Studio Build lägger redan till /nr:false 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 bygguppgifter 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 du vill fråga. 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 dödläget i utdataströmmen. Om du lägger till ytterligare MSBuild-argument /p:RunWixToolsOutOfProc=true kan du kringgå problemet.

Radslut för flera plattformar

När du kör pipelines på flera plattformar kan du ibland stöta på problem med 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 få rader att sluta i LF på lagringsplatsen men CRLF i arbetskatalogen i Windows.

De flesta Windows-verktyg är bra med LF-slut, och det här automatiska beteendet kan orsaka fler problem än det 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 " (enskilt citattecken) tillagt

Om din pipeline innehåller ett Bash-skript som anger variabler med kommandot ##vso kan du se ytterligare ' ett tillägg till 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 upprepar det till stdout. Detta gör att agenten ##vso ser kommandot 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

Vid 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 MY_VAR anges till rätt värde, "my_value". Men när den ser den andra raden bearbetar agenten allt till slutet av raden. MY_VAR anges till "my_value".

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

När ett Python-program distribueras körs i vissa fall en CI/CD-pipeline och koden har distribuerats, men den requirements.txt fil som ansvarar för att installera alla beroendebibliotek körs inte.

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.

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-loggarna 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 utförliga loggar. När pipelinen är klar söker du i loggarnaAgent environment resources efter 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 Azure File Copy-uppgiften 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.

Nästa steg