Delen via


Problemen met pijplijnruns oplossen

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

Als de pijplijnuitvoering niet kan worden voltooid, gebruikt u de diagnostische gegevens en logboeken op de overzichtspagina van de pijplijnuitvoering om het probleem op te lossen. Deze handleiding bevat instructies voor het diagnosticeren van pijplijnfouten met behulp van logboeken, hulpprogramma's voor foutanalyse en algemene technieken voor probleemoplossing. Meer informatie over het identificeren van hoofdoorzaken en het implementeren van oplossingen om uw pijplijnen soepel te laten werken.

Schermopname van de overzichtspagina pijplijnuitvoering met diagnostische gegevens.

Logboeken weergeven

Selecteer het foutbericht om logboeken weer te geven voor de taak die niet is voltooid.

Schermopname van een taakfoutbericht op de overzichtspagina van pijplijnuitvoering.

Op de logboekpagina wordt de geselecteerde fout weergegeven. In dit voorbeeld is er een fout opgetreden in de cmd-line taak, waarbij de opdracht echo wordt ingevoerd als ech.

Schermopname van diagnostisch logboek voor de pijplijnuitvoering.

U kunt het onbewerkte logboek voor de taak weergeven door onbewerkt logboek weergeven te kiezen en u kunt zoeken in het logboek met behulp van Zoeken.

Schermopname van opties voor logboekweergave in Azure DevOps.

Scan de logboeken van de mislukte taak op foutinformatie en aanwijzingen over waarom de taak mislukt. Standaard worden niet-gedetailleerde logboeken gegenereerd door een pijplijn. Als de standaardlogboeken niet de oorzaak van het probleem aangeven, kunt u meer informatie krijgen door uitgebreide logboeken te configureren .

Foutanalysepagina

Hulp bij het oplossen van problemen is beschikbaar via de pagina Foutanalyse . Beweeg de muisaanwijzer over de foutinformatielijn en kies het pictogram Analyse weergeven .

Schermopname van het pictogram voor analyseweergave op de overzichtspagina van pijplijnruns.

Schermopname van het pictogram voor weergaveanalyse voor Azure DevOps Server.

Kies Agent weergeven voor zelf-gehoste agents (of Over de installatiekopie van gehoste agent voor door Microsoft gehoste agents) om meer informatie te zien over de agent die wordt gebruikt om de pijplijn te draaien, en Logboek weergeven om de pijplijnuitvoeringslogboeken te bekijken.

Schermopname van de pagina foutanalyse in de Azure DevOps-portal.

Kies de naam van de taak onder uitvoeringsdetails om informatie over de taak weer te geven.

Schermopname van taakgegevens uit foutanalyse.

In dit voorbeeld ziet u dat er een fout optreedt in de Value van de Script. Kies Over deze taak om de documentatie voor de taak weer te geven.

Als het probleem niet duidelijk is op de overzichtspagina van de pijplijnuitvoering of bij het bekijken van de logboeken, raadpleegt u de sectie Veelvoorkomende problemen, en zie Controleer logboeken om pijplijnproblemen te diagnosticeren voor informatie over het downloaden van volledige logboeken die meer diagnostische informatie bevatten.

Veelvoorkomende problemen

Taakinzichten voor mislukte pijplijnuitvoeringen

Azure DevOps biedt een instelling voor taakinzichten voor mislukte pijplijnuitvoeringen , die, indien ingeschakeld, pop-upmeldingen over buildfouten biedt met een koppeling om een rapport weer te geven.

Schermopname van metrische gegevens voor taakinzichten.

Als u deze instelling wilt configureren, gaat u naar Preview-functies, zoekt u Taakinzichten voor mislukte pijplijnuitvoeringen en kiest u de gewenste instelling.

Schermopname van de instelling voor taakinzichten voor mislukte pijplijnuitvoeringen.

Meldingen voor mislukte uitvoeringen

Azure DevOps bevat ingebouwde meldingen voor mislukte pijplijnuitvoeringen. Meldingen inschakelen:

  1. Ga naar Project-instellingenmeldingen> voor uw project.
  2. Kies welk type melding u wilt ontvangen. Als u een melding wilt ontvangen telkens wanneer een pijplijnuitvoering mislukt, selecteert u Een build mislukt.

Schermopname van meldingen in projectinstellingen.

Deze pijplijn heeft toestemming nodig voor toegang tot een resource voordat deze run kan doorgaan

Als uw pijplijn niet start, of als u een foutbericht ontvangt zoals This pipeline needs permission to access a resource before this run can continue, controleer dan of de pijplijn wacht op een autorisatie van een resource, zoals een serviceverbinding of agentpool.

  1. Ga naar de pijplijn en start handmatig een run.
  2. Het bericht Deze pijplijn heeft toestemming nodig voor toegang tot een bron voordat deze actie kan worden voortgezet . Selecteer Weergave naast het bericht.
  3. Selecteer In het scherm Wachten op revisiede optie Toestaan en selecteer op het bevestigingsscherm opnieuw Toestaan .

Met deze actie wordt de pijplijn expliciet toegevoegd als geautoriseerde gebruiker van de resource.

Er zijn twee manieren om pijplijnen te autoriseren voor toegang tot uw agentenpool.

Specifieke pijplijnen autoriseren

U kunt specifieke pijplijnen afzonderlijk autoriseren om uit te voeren in een agentgroep door de procedure in de vorige sectie te volgen wanneer u een bericht ontvangt zoals This pipeline needs permission to access a resource before this run can continue.

U kunt ook handmatig pijplijnen toevoegen aan en verwijderen uit de geautoriseerde lijst door de volgende procedure uit te voeren. Deze procedure wordt uitgevoerd op projectniveau in uw Azure DevOps-organisatie.

  1. Ga in Azure DevOps naar Project-instellingen, agentpools, kies uw zelf-hostende pool en kies Beveiliging.
  2. Kies ervoor + om een pijplijn toe te voegen aan de geautoriseerde lijst.
  3. Kies X(Toegang intrekken) om een pijplijn uit de geautoriseerde lijst te verwijderen.

Open access configureren

Met sommige resources kunt u Open Access configureren, zodat voor elke nieuwe pijplijndefinitie geen expliciete autorisatie is vereist.

Voor het configureren van Open Access zijn machtigingen van de projectbeheerder vereist.

Open access configureren voor agentpools:

  1. Ga in Azure DevOps naar Project-instellingen, agentpools, kies uw zelf-hostende pool en kies Beveiliging.
  2. Kies Meer acties, Toegang openen, open toegang inschakelen en kies Opnieuw openen om te bevestigen.
  3. Als u de open toegang wilt intrekken, kiest u De machtiging Beperken.

Als u wilt controleren of Open Access beschikbaar is voor andere resourcetypen, raadpleegt u Beveiliging beheren in Azure Pipelines en zoekt u naar Open Access.

Zie Pijplijnmachtigingen instellen voor een afzonderlijke agentgroep en pijplijnmachtigingen voor meer informatie over Open Access voor agentpools.

Time-out van taak

Een pijplijn kan lange tijd draaien en vervolgens mislukken vanwege een time-out van een opdracht. De time-out van opdrachten hangt nauw af van de gebruikte agent. Gratis door Microsoft gehoste agents hebben een time-out van maximaal 60 minuten per taak voor een privé-opslagplaats en 360 minuten voor een openbare opslagplaats.

Als u de maximale time-out voor een taak wilt verhogen, kunt u kiezen voor een van de volgende opties.

  • Koop een door Microsoft gehoste agent die u 360 minuten geeft voor alle taken, ongeacht de gebruikte opslagplaats
  • Gebruik een zelfgehoste agent om eventuele time-outproblemen vanwege de agent uit te sluiten.

Meer informatie over time-out voor taken.

Notitie

Als er een time-out optreedt voor uw door Microsoft gehoste agenttaken, controleert u of de time-out voor uw pijplijn is ingesteld op een hogere waarde dan de maximale time-out voor een taak. Zie Time-outs om dit te controleren.

Problemen met het downloaden van code

Mijn pijplijn mislukt bij een uitcheckstap

Als u een stap in een checkout Azure Repos Git-opslagplaats in uw organisatie gebruikt die zich in een ander project bevindt dan uw pijplijn, moet u ervoor zorgen dat de instelling Beperk de taakautorisatie tot het huidige project is uitgeschakeld, of volg de stappen in Scoped build-identiteiten om ervoor te zorgen dat uw pijplijn toegang heeft tot de opslagplaats.

Wanneer uw pijplijn geen toegang heeft tot de opslagplaats vanwege een beperkt bereik voor taakautorisatie, ontvangt u de fout Git fetch failed with exit code 128 en bevatten uw logboeken een vermelding die vergelijkbaar is met 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.

Als uw pijplijn onmiddellijk mislukt met Could not find a project that corresponds with the repository, moet u ervoor zorgen dat de naam van uw project of repository juist is in de checkout-stap of in de declaratie van de repository-resource.

Problemen met Team Foundation Version Control (TFVC)

Bronnen ophalen die sommige bestanden niet downloaden

Mogelijk ziet u vanuit de tf get opdracht een bericht in het logboek 'Alle bestanden up-to-date'. Controleer of de ingebouwde service-identiteit gemachtigd is om de bronnen te downloaden. Ofwel de identiteit Project Collection Build Service ofwel Project Build Service moet toestemming hebben om de bronbestanden te downloaden, afhankelijk van het geselecteerde autorisatiebereik op het tabblad Algemeen van de build-pijplijn. In de versiebeheerwebgebruikersinterface kunt u door de projectbestanden bladeren op elk niveau van de maphiërarchie en de beveiligingsinstellingen controleren.

Bronnen ophalen via Team Foundation Proxy

De eenvoudigste manier om de agent te configureren voor het ophalen van bronnen via een Team Foundation-proxy, is het instellen van een omgevingsvariabele TFSPROXY die verwijst naar de TFVC-proxyserver voor de uitvoering van de agent als gebruiker.

Ramen:

    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

Mijn pijplijn mislukt bij een commandolinestap, zoals MSBUILD.

Het is handig om te bepalen of een build- of releasefout het gevolg is van een Azure Pipelines-productprobleem (agent of taken). Build- en releasefouten kunnen ook het gevolg zijn van externe opdrachten.

Controleer de logboeken op de exacte opdrachtregel die wordt uitgevoerd door de mislukte taak. Als u de opdracht lokaal probeert uit te voeren vanaf de opdrachtregel, kan het probleem zich opnieuw voordoen. Het kan handig zijn om de opdracht lokaal uit te voeren vanaf uw eigen computer en/of u aan te melden bij de computer en de opdracht uit te voeren als het serviceaccount.

Is het probleem bijvoorbeeld opgetreden tijdens het MSBuild-onderdeel van uw build-pijplijn (gebruikt u bijvoorbeeld de MSBuild - of Visual Studio Build-taak )? Zo ja, voer dan dezelfde MSBuild-opdracht uit op een lokale computer met dezelfde argumenten. Als u het probleem op een lokale computer kunt reproduceren, zijn de volgende stappen om het MSBuild-probleem te onderzoeken.

Bestandsindeling

De locatie van hulpprogramma's, bibliotheken, headers en andere dingen die nodig zijn voor een build, kan afwijken van de gehoste agent dan van uw lokale computer. Als een build mislukt omdat een van deze bestanden niet kan worden gevonden, kunt u de onderstaande scripts gebruiken om de indeling van de agent te controleren. Dit kan u helpen bij het opsporen van het ontbrekende bestand.

Maak een nieuwe YAML-pijplijn op een tijdelijke locatie (bijvoorbeeld een nieuwe opslagplaats die is gemaakt voor het oplossen van problemen). Zoals geschreven, doorzoekt het script mappen op uw pad. U kunt desgewenst de SEARCH_PATH= regel bewerken om op andere plaatsen te zoeken.

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

Verschillen tussen lokale opdrachtprompt en agent

Houd er rekening mee dat sommige verschillen van kracht zijn bij het uitvoeren van een opdracht op een lokale computer en wanneer een build of release wordt uitgevoerd op een agent. Als de agent is geconfigureerd voor uitvoering als een service in Linux, macOS of Windows, wordt deze niet uitgevoerd binnen een interactieve aangemelde sessie. Zonder een interactieve aangemelde sessie zijn er beperkingen in de interactie met de gebruikersinterface en andere beperkingen.

Fouten bij het gebruik van bestanden of mappen

File or folder in use fouten worden aangegeven door foutberichten zoals:

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

Stappen voor probleemoplossing:

Bestanden en mappen in gebruik detecteren

In Windows kunnen hulpprogramma's zoals Process Monitor een tracering van bestandsevenementen onder een specifieke map vastleggen. Of voor een momentopname in de tijd kunnen hulpprogramma's zoals Process Explorer of Handle worden gebruikt.

Antivirusuitsluiting

Antivirussoftware die uw bestanden scant, kan fouten veroorzaken bij het gebruik van bestanden of mappen tijdens een build of release. Het toevoegen van een anti-virusuitsluiting voor uw agentmap en geconfigureerde 'werkmap' kan helpen bij het identificeren van antivirussoftware als het verstorende proces.

MSBuild en /nodeHergebruik:false

Als u MSBuild aanroept tijdens uw build, moet u het argument doorgeven /nodeReuse:false (korte vorm /nr:false). Anders blijven MSBuild-processen actief nadat de build is voltooid. De processen blijven enige tijd in afwachting van een potentiële volgende build.

Deze functie van MSBuild kan interfereren met pogingen om een map te verwijderen of te verplaatsen - vanwege een conflict met de werkmap van de MSBuild-processen.

De MSBuild- en Visual Studio Build-taken voegen al /nr:false toe aan de argumenten die zijn doorgegeven aan MSBuild. Als u ECHTER MSBuild aanroept vanuit uw eigen script, moet u het argument opgeven.

MSBuild en /maxcpucount:[n]

Standaard voeren de buildtaken zoals MSBuild en Visual Studio Build MSBuild uit met de /m switch. In sommige gevallen kan dit problemen veroorzaken, zoals problemen met meerdere procesbestanden.

Probeer het argument /m:1 toe te voegen aan uw buildtaken om MSBuild te dwingen slechts één proces tegelijk uit te voeren.

Problemen met bestanden die in gebruik zijn, kunnen optreden bij het gebruik van de functionaliteit voor gelijktijdige processen van MSBuild. Als u het argument /maxcpucount:[n] (korte vorm /m:[n]) niet opgeeft, geeft MSBuild de opdracht om slechts één proces te gebruiken. Als u de MSBuild- of Visual Studio Build-taken gebruikt, moet u mogelijk '/m:1' opgeven om het argument '/m' te overschrijven dat standaard wordt toegevoegd.

Onregelmatige of inconsistente MSBuild-fouten

Als u onregelmatige of inconsistente MSBuild-fouten ondervindt, probeert u MSBuild te instrueren om alleen één proces te gebruiken. Onregelmatige of inconsistente fouten kunnen erop wijzen dat uw doelconfiguratie niet compatibel is met de functie gelijktijdig proces van MSBuild. Zie MSBuild en /maxcpucount:[n].

Proces reageert niet meer

Proces reageert niet meer op oorzaken en stappen voor probleemoplossing:

Wachten op invoer

Een proces dat niet meer reageert, kan erop wijzen dat een proces wacht op invoer.

Het uitvoeren van de agent vanaf de commando-regel van een interactieve aangemelde sessie kan helpen om te bepalen of een proces een dialoogvenster voor invoer opent.

Het uitvoeren van de agent als een service kan helpen om te voorkomen dat programma's om invoer vragen. In .NET kunnen programma's bijvoorbeeld afhankelijk zijn van de Boolean System.Environment.UserInteractive om te bepalen of er een prompt moet worden weergegeven. Wanneer de agent wordt uitgevoerd als een Windows-service, is de waarde onwaar.

Procesdump

Het analyseren van een dump van het proces kan helpen bij het identificeren waarop een vastgelopen proces wacht.

WiX-project

Het bouwen van een WiX-project wanneer aangepaste MSBuild-loggers zijn ingeschakeld, kan ertoe leiden dat WiX vastloopt terwijl er op de uitvoerstroom wordt gewacht. Het toevoegen van het extra MSBuild-argument /p:RunWixToolsOutOfProc=true werkt rond het probleem.

Lijneinden voor meerdere platforms

Wanneer u pijplijnen op meerdere platforms uitvoert, kunt u soms problemen ondervinden met verschillende lijneinden. In het verleden gebruikten Linux en macOS linefeed-tekens (LF), terwijl Windows een carriage return plus een linefeed (CRLF) gebruikte. Git probeert het verschil te compenseren door regels automatisch te laten eindigen met LF in de opslagplaats, maar met CRLF in de werkmap op Windows.

De meeste Windows-hulpprogramma's kunnen probleemloos overweg met alleen LF-eindes, en dit automatische gedrag kan meer problemen veroorzaken dan het oplost. Als u problemen ondervindt in verband met regeleinden, raden we u aan Git zo te configureren dat er overal een voorkeur voor LF wordt ingesteld. U doet dit door een .gitattributes-bestand toe te voegen aan de hoofdmap van uw opslagplaats. Voeg in dat bestand de volgende regel toe:

* text eol=lf

Variabelen waaraan ' (enkele aanhalingsteken) is toegevoegd

Als uw pijplijn een Bash-script bevat dat variabelen instelt met behulp van de ##vso opdracht, kan het zijn dat een andere waarde ' is toegevoegd aan de waarde van de variabele die u instelt. Dit gebeurt vanwege een interactie met set -x. De oplossing is om tijdelijk set -x uit te schakelen voordat u een variabele instelt. De Bash-syntaxis hiervoor is set +x.

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

Waarom gebeurt dit?

Veel Bash-scripts bevatten de set -x opdracht om te helpen bij foutopsporing. Bash traceert precies welke opdracht is uitgevoerd en echo deze naar stdout. Dit zorgt ervoor dat de agent de ##vso opdracht tweemaal ziet en de tweede keer dat Bash het ' teken aan het einde heeft toegevoegd.

Denk bijvoorbeeld aan deze pijplijn:

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

Op stdout ziet de agent twee regels:

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

Wanneer de agent de eerste regel ziet, wordt MY_VAR ingesteld op de juiste waarde, 'my_value'. Wanneer de tweede regel echter wordt weergegeven, verwerkt de agent alles tot het einde van de regel. MY_VAR is ingesteld op 'my_value'.

Bibliotheken worden niet geïnstalleerd voor de Python-toepassing wanneer het script wordt uitgevoerd

Wanneer een Python-toepassing wordt geïmplementeerd, wordt in sommige gevallen een CI/CD-pijplijn uitgevoerd en wordt de code geïmplementeerd, maar het requirements.txt-bestand dat verantwoordelijk is voor het installeren van alle afhankelijkheidsbibliotheken, wordt niet uitgevoerd.

Als u de afhankelijkheden wilt installeren, gebruikt u een script na de implementatie in de App Service-implementatietaak. In het volgende voorbeeld ziet u de opdracht die u moet gebruiken in het script na de implementatie. U kunt het script voor uw scenario bijwerken.

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

Als u problemen met betrekking tot serviceverbindingen wilt oplossen, raadpleegt u Het oplossen van problemen met de serviceverbinding. Als u specifiek problemen met serviceverbindingen wilt oplossen met behulp van workload-identiteit voor verificatie, raadpleegt u Problemen met serviceverbindingen van workload-identiteit oplossen.

De pijplijn ontvangt geen signalen meer van de agent.

Als uw pijplijn mislukt met een bericht zoals We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection., controleert u het resourcegebruik van de agent om te zien of de agentcomputer onvoldoende resources heeft. Vanaf Sprint 228bevatten Azure Pipelines-logboeken metrische gegevens over resourcegebruik voor elke stap.

Wanneer u Azure DevOps Services gebruikt, kunt u het gebruik van resources in de logboeken bekijken, waaronder schijfgebruik, geheugengebruik en CPU-gebruik, door uitgebreide logboeken in te schakelen. Wanneer de pijplijn is voltooid, zoekt u in de logboeken naar Agent environment resources vermeldingen voor elke stap.

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%

Voor informatie over het vastleggen van aanvullende logbestanden voor resourcegebruik, zie Resourcegebruik vastleggen.

Opslagverkenner inschakelen voor het implementeren van statische inhoud, zoals .css en .js naar een statische website vanuit Azure DevOps via Azure Pipelines

In dit scenario kunt u de Azure File Copy-taak gebruiken om inhoud naar de website te uploaden. U kunt een van de hulpprogramma's gebruiken die worden beschreven in Inhoud uploaden om inhoud te uploaden naar de webcontainer.

Volgende stappen