Ř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.

Snímek obrazovky se stránkou souhrnu spuštění kanálu

Zobrazení protokolů

Výběrem chybové zprávy zobrazíte protokoly pro úlohu, která se nepovedla dokončit.

Snímek obrazovky s chybovou zprávou úkolu na stránce souhrnu spuštění kanálu

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.

Snímek obrazovky s diagnostickým protokolem pro spuštění kanálu

Nezpracovaný protokol pro úlohu můžete zobrazit tak, že zvolíte Zobrazit nezpracovaný protokol a protokol můžete prohledávat pomocí funkce Najít.

Snímek obrazovky s možnostmi zobrazení protokolu v Azure DevOps

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 .

Snímek obrazovky s ikonou zobrazení analýzy na stránce souhrnu spuštění kanálu

Snímek obrazovky s ikonou analýzy zobrazení pro Azure DevOps Server

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.

Snímek obrazovky se stránkou analýzy chyb na portálu Azure DevOps

Zvolte název úlohy pod podrobnostmi o spuštění a zobrazte informace o úkolu.

Snímek obrazovky s podrobnostmi úkolu z analýzy chyb

V tomto příkladu vidíte, že v objektu ValueScript. 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

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.

Snímek obrazovky s metrikami přehledů úkolů

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í.

Snímek obrazovky s přehledy úloh pro nastavení neúspěšných spuštění kanálu

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 repositoryujistě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

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í

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

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 protokolechAgent 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 .

Další kroky