Problemen met pijplijnuitvoeringen oplossen
Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019
Als de pijplijnuitvoering niet kan worden voltooid, kunt u de diagnostische gegevens en logboeken van de overzichtspagina van de pijplijnuitvoering gebruiken om het probleem op te lossen.
Logboeken weergeven
Selecteer het foutbericht om de logboeken weer te geven voor de taak die niet is voltooid.
De logboekpagina wordt weergegeven, waarbij de fout is geselecteerd. In dit voorbeeld is er een fout opgetreden in de cmd-line taak, waarbij de echo opdracht wordt ingevoerd als ech.
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.
Scan de logboeken van de mislukte taak op foutinformatie en aanwijzingen over waarom de taak mislukt. Standaard worden niet-uitgebreide logboeken gegenereerd door een pijplijnuitvoering. Als de standaardlogboeken niet de oorzaak van het probleem aangeven, kunt u meer informatie krijgen door uitgebreide logboeken te configureren.
Pagina Foutanalyse
Hulp bij het oplossen van problemen is beschikbaar via de pagina Foutanalyse . Beweeg de muisaanwijzer over de foutinformatielijn en kies het pictogram Analyse weergeven .
Kies Agent weergeven voor zelf-hostende agents (of Over de installatiekopie van gehoste agent voor door Microsoft gehoste agents) voor meer informatie over de agent die wordt gebruikt voor het uitvoeren van de pijplijn en het logboek weergeven om de pijplijnuitvoeringslogboeken weer te geven.
Kies de naam van de onderstaande uitvoeringsdetails om informatie over de taak weer te geven.
In dit voorbeeld ziet u dat er een fout is opgetreden in de Value Script. Kies Over deze taak om de documentatie voor de taak weer te geven.
Als het probleem niet zichtbaar is op de overzichtspagina van de pijplijnuitvoering of door de logboeken bladert, raadpleegt u de volgende sectie Veelvoorkomende problemen en raadpleegt u Logboeken controleren om problemen met pijplijnen vast te stellen voor informatie over het downloaden van volledige logboeken die aanvullende diagnostische informatie bevatten.
Algemene problemen
- Time-out van taak
- Problemen met het downloaden van code
- Mijn pijplijn mislukt in een opdrachtregelstap, zoals MSBUILD
- Fouten bij het gebruik van bestanden of mappen
- Onregelmatige of inconsistente MSBuild-fouten
- Proces reageert niet meer
- Lijn uiteinden voor meerdere platforms
- Variabelen waaraan ' (enkele aanhalingsteken) is toegevoegd
- Problemen met betrekking tot de verbinding
- Pijplijn is gestopt met horen van agent
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.
Als u deze instelling wilt configureren, gaat u naar Preview-functies, zoekt u Taakinzichten voor mislukte pijplijnuitvoeringen en kiest u de gewenste instelling.
Time-out van taak
Een pijplijn kan lang worden uitgevoerd en kan vervolgens mislukken vanwege een time-out van de taak. Time-out van taken 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
- Een zelf-hostende agent gebruiken om time-outproblemen vanwege de agent uit te sluiten
Meer informatie over time-outs voor taken.
Notitie
Als er een time-out optreedt voor uw door Microsoft gehoste agenttaken, moet u ervoor zorgen dat u geen time-out voor een pijplijn hebt opgegeven die kleiner is 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 Git-opslagplaats voor Azure-opslagplaatsen in uw organisatie gebruikt die zich in een ander project bevindt dan uw pijplijn, moet u ervoor zorgen dat het bereik voor taakautorisatie beperken tot de huidige projectinstelling is uitgeschakeld of volg de stappen in build-identiteiten met bereik 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, wordt de fout Git fetch failed with exit code 128 weergegeven 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, Could not find a project that corresponds with the repositorycontroleert u of de naam van uw project en de opslagplaats juist zijn in de stap of in de checkout declaratie van de opslagplaatsresource.
Problemen met Team Foundation Version Control (TFVC)
Bronnen ophalen die sommige bestanden niet downloaden
Dit kan worden gekenmerkt door een bericht in het logboek 'Alle bestanden up-to-date' van de tf get opdracht. Controleer of de ingebouwde service-identiteit gemachtigd is om de bronnen te downloaden. De identity Project Collection Build Service of Project Build Service heeft toestemming nodig om de bronnen 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.
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
Mijn pijplijn mislukt in een opdrachtregelstap, zoals MSBUILD
Het is handig om te beperken of een build- of releasefout het resultaat is van een Azure Pipelines-/TFS-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 worden gereproduceerd. 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 probleemoplossing).
Zoals geschreven, doorzoekt het script mappen op uw pad.
U kunt de SEARCH_PATH= regel desgewenst 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 bestaan er interactie met de gebruikersinterface en andere beperkingen.
Fouten bij het gebruik van bestanden of mappen
File or folder in use fouten worden vaak 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
- Uitsluiting van virussen
- MSBuild en /nodeReuse:false
- MSBuild en /maxcpucount:[n]
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.
Uitsluiting van virussen
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 /nodeReuse:false
Als u MSBuild aanroept tijdens uw build, moet u het argument /nodeReuse:false doorgeven (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 problemen veroorzaken met pogingen om een map te verwijderen of te verplaatsen- vanwege een conflict met de werkmap van het MSBuild-proces(en).
De MSBuild- en Visual Studio Build-taken voegen al toe /nr:false 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.
Voeg het /m:1 argument toe aan uw buildtaken om MSBuild te dwingen slechts één proces tegelijk uit te voeren.
Problemen met bestand in gebruik kunnen ertoe leiden dat de functie gelijktijdig proces van MSBuild wordt gebruikt. Als u het argument /maxcpucount:[n] (korte vorm /m:[n]) niet opgeeft, geeft MSBuild alleen opdracht om éé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 opdrachtregel van een interactieve aangemelde sessie kan helpen om te bepalen of een proces wordt gevraagd met een dialoogvenster voor invoer.
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 Booleaanse waarde System.Environment.UserInteractive om te bepalen of dit moet worden gevraagd. 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 van waar een impasseproces op wacht.
WiX-project
Het bouwen van een WiX-project wanneer aangepaste MSBuild-loggers zijn ingeschakeld, kan ertoe leiden dat WiX een impasse veroorzaakt die wacht op de uitvoerstroom. Als u het extra MSBuild-argument /p:RunWixToolsOutOfProc=true toevoegt, wordt het probleem omzeild.
Lijn uiteinden 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 linefeedtekens (LF) terwijl Windows een regelterugloop plus een linefeed (CRLF) gebruikte. Git probeert het verschil te compenseren door regels automatisch te maken in LF in de opslagplaats, maar CRLF in de werkmap in Windows.
De meeste Windows-hulpprogramma's zijn in orde met alleen-LF-einden en dit automatische gedrag kan meer problemen veroorzaken dan het oplost.
Als u problemen ondervindt op basis van regeleinden, raden we u aan Git te configureren om overal de voorkeur te geven aan LF.
Voeg hiervoor een .gitattributes bestand toe 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 waarmee variabelen worden ingesteld met behulp van de ##vso opdracht, ziet u mogelijk een extra ' 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 echot 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, MY_VAR wordt deze ingesteld op de juiste waarde, 'my_value'.
Wanneer de tweede regel echter wordt weergegeven, verwerkt de agent alles aan het einde van de regel.
MY_VAR wordt 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
Problemen met betrekking tot de verbinding
Als u problemen met betrekking tot serviceverbindingen wilt oplossen, raadpleegt u Het oplossen van problemen met de serviceverbinding.
Pijplijn is gestopt met horen van 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 228 bevatten Azure Pipelines-logboeken metrische gegevens over resourcegebruik voor elke stap.
Wanneer u Azure DevOps Services gebruikt, kunt u het resourcegebruik in de logboeken zien, 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%
Zie Details van resourcegebruik vastleggen voor meer informatie over het vastleggen van aanvullende resourcegebruikslogboeken.
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.