Řešení potíží se spuštěními kanálů
Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019
Pokud se spuštění kanálu nepodaří dokončit, můžete k řešení tohoto problému použít diagnostické informace a protokoly, které poskytuje stránka souhrnu spuštění kanálu.
Zobrazení protokolů
Výběrem chybové zprávy zobrazíte protokoly pro úlohu, která se nepovedla dokončit.
Zobrazí se stránka protokolů s vybranou chybou. V tomto příkladu cmd-line
je v úkolu chyba, kde echo
je příkaz zadán jako ech
.
Nezpracovaný protokol pro úlohu můžete zobrazit tak, že zvolíte Zobrazit nezpracovaný protokol a protokol můžete prohledávat pomocí funkce Najít.
V protokolech neúspěšné úlohy vyhledejte informace o chybě a vodítka, proč úloha selhává. Ve výchozím nastavení se neverbose protokoly generují spuštěním kanálu. Pokud výchozí protokoly neoznačují příčinu problému, můžete získat další informace konfigurací podrobných protokolů.
Stránka analýza chyb
Pomoc s řešením potíží je k dispozici na stránce Analýza chyb. Přesuňte myš na informační řádek s informacemi o chybě a zvolte ikonu Zobrazit analýzu .
Zvolte Zobrazit agenta pro agenty v místním prostředí (nebo o imagi hostovaného agenta pro agenty hostované Microsoftem) a zobrazte další informace o agentu použitém ke spuštění kanálu a zobrazte protokoly spuštění kanálu.
Zvolte název úlohy pod podrobnostmi o spuštění a zobrazte informace o úkolu.
V tomto příkladu vidíte, že v objektu Value
Script
. Zvolte O této úloze a zobrazte dokumentaci k úkolu.
Pokud se problém nezobrazuje ze stránky se souhrnem spuštění kanálu nebo procházením protokolů, projděte si následující část Běžné problémy a projděte si protokoly a projděte si informace o stahování úplných protokolů, které obsahují další diagnostické informace.
Běžné problémy
- Vypršení časového limitu úlohy
- Problémy se stažením kódu
- Kanál selhává v kroku příkazového řádku, jako je MSBUILD
- Chyby používaného souboru nebo složky
- Přerušovaná nebo nekonzistentní selhání MSBuild
- Proces přestane reagovat
- Konce řádků pro různé platformy
- Proměnné, které mají připojenou jednoduchou uvozovku
- Problémy související s připojením služby
- Kanál přestal slyšet od agenta
Přehledy úloh pro neúspěšná spuštění kanálu
Azure DevOps poskytuje Přehledy úlohy pro nastavení neúspěšných spuštění kanálu, které v případě povolení poskytuje automaticky otevíraná oznámení o selhání sestavení s odkazem pro zobrazení sestavy.
Pokud chcete toto nastavení nakonfigurovat, přejděte na funkce ve verzi Preview, vyhledejte Přehledy úlohy pro neúspěšná spuštění kanálu a zvolte požadované nastavení.
Vypršení časového limitu úlohy
Kanál může běžet dlouhou dobu a pak selžou kvůli vypršení časového limitu úlohy. Časový limit úlohy úzce závisí na používaném agentu. Bezplatní agenti hostovaní Microsoftem mají maximální časový limit 60 minut na úlohu pro soukromé úložiště a 360 minut pro veřejné úložiště. Pokud chcete zvýšit maximální časový limit pro úlohu, můžete zvolit některou z následujících možností.
- Kupte si agenta hostovaného Microsoftem, který vám poskytne 360 minut pro všechny úlohy bez ohledu na použité úložiště
- Použijte samostatně hostovaného agenta, abyste vyloučili případné problémy s vypršením časového limitu způsobené agentem
Přečtěte si další informace o vypršení časového limitu úlohy.
Poznámka:
Pokud dochází k vypršení časového limitu úloh agenta hostovaného Microsoftem, ujistěte se, že jste nezadali časový limit kanálu, který je menší než maximální časový limit úlohy. Pokud to chcete zkontrolovat, podívejte se na časové limity.
Problémy se stažením kódu
Kanál selhává v kroku rezervace
Pokud používáte checkout
krok v úložišti Git Azure Repos ve vaší organizaci, který je v jiném projektu než kanál, ujistěte se, že je obor autorizace úlohy limitu na aktuální nastavení projektu zakázaný, nebo postupujte podle kroků v identitách sestavení s vymezeným oborem a ujistěte se, že váš kanál má přístup k úložišti.
Pokud váš kanál nemá přístup k úložišti kvůli omezenému rozsahu autorizace úloh, zobrazí se chyba Git fetch failed with exit code 128
a vaše protokoly budou obsahovat položku podobnou této: 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.
Pokud váš kanál selhává okamžitě, Could not find a project that corresponds with the repository
ujistěte se, že váš projekt a název úložiště jsou v checkout
kroku nebo deklaraci zdroje úložiště správné.
Problémy s Správa verzí Team Foundation (TFVC)
- Získání zdrojů, které nestahují některé soubory
- Získání zdrojů prostřednictvím proxy team foundation
Získání zdrojů, které nestahují některé soubory
To může být charakterizováno zprávou v protokolu "Všechny soubory aktuální" z tf get
příkazu. Ověřte, že integrovaná identita služby má oprávnění ke stažení zdrojů. Buď služba sestavení kolekce projektů nebo služba sestavení projektu bude potřebovat oprávnění ke stažení zdrojů v závislosti na vybraném oboru autorizace na kartě Obecné kanálu buildu. Ve webovém uživatelském rozhraní správy verzí můžete procházet soubory projektu na libovolné úrovni hierarchie složek a zkontrolovat nastavení zabezpečení.
Získání zdrojů prostřednictvím proxy team foundation
Nejjednodušší způsob, jak nakonfigurovat agenta pro získání zdrojů přes Team Foundation Proxy, je nastavená proměnná TFSPROXY
prostředí, která ukazuje na proxy server TFVC pro spuštění agenta jako uživatel.
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
Kanál selhává v kroku příkazového řádku, jako je MSBUILD
Je užitečné zúžit, jestli je selhání sestavení nebo vydání výsledkem problému s produktem Azure Pipelines nebo TFS (agent nebo úlohy). Selhání sestavení a vydání můžou také vést k externím příkazům.
Zkontrolujte protokoly pro přesný příkazový řádek spuštěný neúspěšnou úlohou. Pokus o místní spuštění příkazu z příkazového řádku může problém reprodukovat. Může být užitečné spustit příkaz místně z vlastního počítače a/nebo se přihlásit k počítači a spustit příkaz jako účet služby.
Dochází například k problému během části kanálu sestavení NÁSTROJE MSBuild (například používáte úlohu MSBuild nebo sestavení sady Visual Studio)? Pokud ano, zkuste spustit stejný příkaz MSBuild na místním počítači pomocí stejných argumentů. Pokud můžete problém reprodukovat na místním počítači, je dalším postupem prozkoumání problému nástroje MSBuild .
Rozložení souboru
Umístění nástrojů, knihoven, hlaviček a dalších věcí potřebných pro sestavení se může lišit v hostovaném agentu než na místním počítači. Pokud sestavení selže, protože nemůže najít jeden z těchto souborů, můžete pomocí následujících skriptů zkontrolovat rozložení agenta. To vám může pomoct zjistit chybějící soubor.
Vytvořte nový kanál YAML v dočasném umístění (např. nové úložiště vytvořené pro účely řešení potíží).
Jak je napsáno, skript prohledává adresáře ve vaší cestě.
Řádek můžete volitelně upravit SEARCH_PATH=
a hledat na jiných místech.
# 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
}
}
Rozdíly mezi místním příkazovým řádkem a agentem
Mějte na paměti, že při provádění příkazu na místním počítači a při spuštění sestavení nebo vydané verze na agenta platí některé rozdíly. Pokud je agent nakonfigurovaný tak, aby běžel jako služba v Linuxu, macOS nebo Windows, není spuštěný v rámci interaktivní přihlášené relace. Bez interaktivní přihlášené relace existují interakce s uživatelským rozhraním a další omezení.
Chyby používaného souboru nebo složky
File or folder in use
chyby jsou často označeny chybovými zprávami, jako jsou:
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 [...]
Postup při řešení potíží:
- Detekce souborů a složek, které se používají
- Vyloučení antivirového programu
- MSBuild a /nodeReuse:false
- MSBuild a /maxcpucount:[n]
Detekce souborů a složek, které se používají
Ve Windows můžou nástroje, jako je Sledování procesů, zachytit trasování událostí souborů v určitém adresáři. Nebo pro snímek v čase je možné použít nástroje, jako je Průzkumník procesů nebo popisovač.
Vyloučení antivirového programu
Antivirová kontrola souborů může způsobit chyby použití souborů nebo složek během sestavení nebo vydání. Přidání vyloučení antivirového softwaru pro adresář agenta a nakonfigurovaná "pracovní složka" může pomoct identifikovat antivirový software jako interferující proces.
MSBuild a /nodeReuse:false
Pokud během sestavení vyvoláte MSBuild, nezapomeňte předat argument /nodeReuse:false
(krátký formulář /nr:false
). V opačném případě zůstanou procesy MSBuild spuštěné po dokončení sestavení. Procesy zůstávají po určitou dobu předvídání potenciálního následného sestavení.
Tato funkce nástroje MSBuild může kolidovat s pokusy o odstranění nebo přesunutí adresáře – kvůli konfliktu s pracovním adresářem procesu MSBuild.
Úlohy SESTAVENÍ nástroje MSBuild a Visual Studio již přidávají /nr:false
do argumentů předaných nástroji MSBuild. Pokud však vyvoláte NÁSTROJ MSBuild z vlastního skriptu, budete muset zadat argument.
MSBuild a /maxcpucount:[n]
Ve výchozím nastavení úlohy sestavení, jako je MSBuild a Visual Studio Build , spouštějí nástroj MSBuild s přepínačem /m
. V některých případech to může způsobit problémy, jako jsou problémy s přístupem k souborům s více procesy.
Zkuste přidat /m:1
argument do úloh sestavení, aby nástroj MSBuild spustil pouze jeden proces najednou.
Problémy s používáním souborů můžou mít za následek využití funkce souběžného procesu nástroje MSBuild. Nezadání argumentu /maxcpucount:[n]
(krátkého formuláře /m:[n]
) dává nástroji MSBuild pokyn, aby používal pouze jeden proces. Pokud používáte úlohy sestavení nástroje MSBuild nebo Visual Studio, možná budete muset zadat /m:1, aby se přepsal argument /m, který je přidaný ve výchozím nastavení.
Přerušovaná nebo nekonzistentní selhání MSBuild
Pokud dochází k přerušovaným nebo nekonzistentním selháním nástroje MSBuild, zkuste nástroj MSBuild instruovat, aby používal pouze jeden proces. Přerušované nebo nekonzistentní chyby můžou znamenat, že vaše cílová konfigurace není kompatibilní s funkcí souběžného procesu nástroje MSBuild. Viz MSBuild a /maxcpucount:[n].
Proces přestane reagovat
Proces přestane reagovat na příčiny a kroky pro řešení potíží:
Čekání na vstup
Proces, který přestane reagovat, může znamenat, že proces čeká na vstup.
Spuštění agenta z příkazového řádku interaktivní přihlášené relace může pomoct určit, jestli se proces zobrazuje s dialogovým oknem pro zadání.
Spuštění agenta jako služby může pomoct eliminovat programy z výzvy k zadání vstupu. Například v .NET můžou programy spoléhat na logickou hodnotu System.Environment.UserInteractive a určit, jestli se má zobrazit výzva. Pokud je agent spuštěný jako služba systému Windows, hodnota je false.
Výpis stavu procesu
Analýza výpisu procesu může pomoct zjistit, na co čeká proces zablokování.
Projekt WiX
Vytvoření projektu WiX, pokud jsou povoleny vlastní protokolovací nástroje MSBuild, může způsobit zablokování WiX čekání na výstupní datový proud. Přidání dalšího argumentu /p:RunWixToolsOutOfProc=true
MSBuild bude tento problém obejít.
Konce řádků pro různé platformy
Když spouštíte kanály na více platformách, můžete někdy narazit na problémy s různými konci čar. V minulosti používaly linuxové a macOS znaky linefeed (LF), zatímco Systém Windows použil návrat na začátek řádku plus řádekfeed (CRLF). Git se snaží vyrovnat rozdíl tím, že automaticky vytvoří řádky končí v úložišti LF, ale CRLF v pracovním adresáři ve Windows.
Většina nástrojů systému Windows je v pořádku pouze s koncovkami LF a toto automatické chování může způsobit více problémů, než řeší.
Pokud narazíte na problémy založené na koncích řádků, doporučujeme nakonfigurovat Git tak, aby preferoval LF všude.
Uděláte to tak, že do kořenového adresáře úložiště přidáte .gitattributes
soubor.
Do tohoto souboru přidejte následující řádek:
* text eol=lf
Proměnné, které mají připojenou jednoduchou uvozovku
Pokud váš kanál obsahuje skript Bash, který nastavuje proměnné pomocí ##vso
příkazu, může se zobrazit další '
připojený k hodnotě proměnné, kterou nastavíte.
K tomu dochází kvůli interakci s příkazem set -x
.
Řešením je před nastavením proměnné dočasně zakázat příkaz set -x
.
Syntaxe Bash pro to je: set +x
.
set +x
echo ##vso[task.setvariable variable=MY_VAR]my_value
set -x
Proč tomu tak je?
Mnoho skriptů Bash obsahuje set -x
příkaz, který vám pomůže s laděním.
Bash bude přesně sledovat, jaký příkaz se spustil, a ozvěn ho stdout.
To způsobí, že agent uvidí ##vso
příkaz dvakrát a druhý čas přidá Bash '
znak na konec.
Představte si například tento kanál:
steps:
- bash: |
set -x
echo ##vso[task.setvariable variable=MY_VAR]my_value
V stdoutu se agent zobrazí dva řádky:
##vso[task.setvariable variable=MY_VAR]my_value
+ echo '##vso[task.setvariable variable=MY_VAR]my_value'
Když agent uvidí první řádek, MY_VAR
nastaví se na správnou hodnotu "my_value".
Když se ale zobrazí druhý řádek, agent zpracuje všechno až na konec řádku.
MY_VAR
bude nastavena na "my_value".
Knihovny se při spuštění skriptu nenainstalují pro aplikaci v Pythonu.
Když je aplikace Pythonu nasazená, v některých případech se kanál CI/CD spustí a kód se úspěšně nasadí, ale soubor requirements.txt , který je zodpovědný za instalaci všech knihoven závislostí, se nespustí.
K instalaci závislostí použijte skript po nasazení v úloze nasazení služby App Service. Následující příklad ukazuje příkaz, který musíte použít ve skriptu po nasazení. Skript můžete aktualizovat pro svůj scénář.
D:\home\python364x64\python.exe -m pip install -r requirements.txt
Problémy související s připojením služby
Informace o řešení potíží souvisejících s připojením služby najdete v tématu Řešení potíží s připojením ke službě.
Kanál přestal slyšet od agenta
Pokud váš kanál selže se zprávou, jako je We stopped hearing from agent <agent name>. Verify the agent machine is running and has a healthy network connection.
, zkontrolujte využití prostředků agenta a zjistěte, jestli počítač agenta nemá prostředky. Od sprintu 228 protokoly Azure Pipelines obsahují metriky využití prostředků pro každý krok.
Pokud používáte Azure DevOps Services, můžete vidět využití prostředků v protokolech, včetně využití disku, využití paměti a využití procesoru, povolením podrobných protokolů. Po dokončení kanálu vyhledejte v protokolech Agent environment resources
položky pro každý krok.
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%
Informace o zachycení dalších protokolů využití prostředků najdete v tématu Zachycení podrobností o využití prostředků.
Povolení Průzkumník služby Storage nasazení statického obsahu, jako je .css a .js na statický web z Azure DevOps prostřednictvím Azure Pipelines
V tomto scénáři můžete použít úlohu Kopírování souborů Azure k nahrání obsahu na web. K nahrání obsahu do webového kontejneru můžete použít kterýkoli z nástrojů popsaných v části Nahrání obsahu .