Sdílet prostřednictvím

Řešení potíží se spuštěním rutin

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022 | Azure DevOps Server 2020

Pokud se spuštění kanálu nedokončí, vyřešte problém pomocí diagnostických informací a protokolů na stránce souhrnu spuštění kanálu. Tato příručka obsahuje pokyny pro diagnostiku selhání kanálu pomocí protokolů, nástrojů pro analýzu chyb a běžných technik řešení potíží. Zjistěte, jak identifikovat původní příčiny a implementovat řešení, aby vaše kanály běžely hladce.

Snímek obrazovky s přehledovou stránkou běhu pipeline s diagnostickými informacemi.

Zobrazení protokolů

Výběrem chybové zprávy zobrazíte protokoly pro úkol, který se nedokončil.

Snímek chyby úlohy na stránce přehledu spuštění pipeline.

Na stránce protokolů se zobrazí vybraná chyba. V tomto příkladu je chyba v úkolu cmd-line, kde je příkaz echo zadán jako ech.

Snímek obrazovky s diagnostickým záznamem běhu 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) pro zobrazení dalších informací o agentu použitém ke spuštění pipeline a Zobrazit protokol pro zobrazení protokolů spuštění pipeline.

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 je chyba v Value objektu Script. Zvolte O této úloze a zobrazte dokumentaci k úkolu.

Pokud není problém patrný ze stránky souhrnu spuštění kanálu nebo při procházení protokolů, zkontrolujte následující část Běžné problémy a podívejte se na protokoly pro diagnostiku problémů s kanálem, kde najdete informace o stahování úplných protokolů, které obsahují více diagnostických informací.

Běžné problémy

Přehledy úloh pro nezdařená spuštění pipeline

Azure DevOps poskytuje nastavení Přehledů úloh pro selhané spuštění kanálu, které po povolení zajišťuje vyskakovací oznámení o selhání sestavení s odkazem na zobrazení zprávy.

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

Pokud chcete toto nastavení nakonfigurovat, přejděte k funkcím ve verzi Preview, vyhledejte Přehledy úloh pro neúspěšná spuštění kanálu a zvolte požadované nastavení.

Snímek obrazovky s přehledy úkolů pro nastavení neúspěšných spuštění pipeline

Oznámení pro neúspěšná spuštění

Azure DevOps zahrnuje oznámení o buildu pro neúspěšná spuštění kanálu. Povolení oznámení:

  1. Přejděte na nastavení projektu>Oznámení pro váš projekt.
  2. Zvolte typ oznámení, které chcete dostávat. Pokud chcete být upozorněni při každém selhání běhu kanálu, vyberte Sestavení selže.

Snímek obrazovky s oznámeními v nastavení projektu

Tento zpracovatelský řetězec potřebuje oprávnění pro přístup k prostředku, než může pokračovat v tomto běhu.

Pokud se váš kanál nespustí, nebo se zobrazí chybová zpráva jako This pipeline needs permission to access a resource before this run can continue, zkontrolujte, jestli kanál čeká na autorizaci pomocí zdroje, jako je připojení služby nebo fond agentů.

  1. Přejděte do pipeline a spusťte ruční běh.
  2. Zpráva Tento kanál potřebuje oprávnění k přístupu k prostředku, než může toto spuštění pokračovat . Vyberte Zobrazit vedle zprávy.
  3. Na obrazovce Čekání na revizi vyberte Povolit a na potvrzovací obrazovce znovu vyberte Povolit .

Tato akce explicitně přidá pipeline jako autorizovaného uživatele prostředku.

Kanály pro přístup k fondu agentů můžete autorizovat dvěma způsoby.

Autorizace konkrétních potrubí

Můžete jednotlivě autorizovat konkrétní pipelines, aby se spouštěly ve fondu agentů, podle postupu v předchozí části, když obdržíte zprávu jako This pipeline needs permission to access a resource before this run can continue.

Kanály můžete také ručně přidávat a odebírat ze seznamu autorizovaných pomocí následujícího postupu. Tento postup se provádí na úrovni projektu ve vaší organizaci Azure DevOps.

  1. V Azure DevOps přejděte do nastavení projektu, fondů agentů, zvolte fond v místním prostředí a zvolte Zabezpečení.
  2. Vyberte + pro přidání potrubí do autorizovaného seznamu.
  3. Zvolte X(Odvolat přístup) a odeberte kanál ze seznamu autorizovaných osob.

Konfigurace otevřeného přístupu

Některé prostředky umožňují nakonfigurovat otevřený přístup tak, aby každá nová definice kanálu nevyžaduje explicitní autorizaci.

Konfigurace otevřeného přístupu vyžaduje oprávnění správce projektu .

Konfigurace Open access pro pooly agentů:

  1. V Azure DevOps přejděte do nastavení projektu, fondů agentů, zvolte fond v místním prostředí a zvolte Zabezpečení.
  2. Zvolte Další akce, Otevřít přístup, povolte otevřený přístup a znovu zvolte Otevřít přístup a potvrďte to.
  3. Pokud chcete odvolat otevřený přístup, zvolte Omezit oprávnění.

Pokud chcete zkontrolovat, jestli je otevřený přístup k dispozici pro jiné typy prostředků, přečtěte si téma Správa zabezpečení ve službě Azure Pipelines a vyhledání přístupu open.

Další informace o otevřeném přístupu pro fondy agentů najdete v tématu Nastavení oprávnění kanálu pro jednotlivé fondy agentů a oprávnění kanálu.

Časový limit úlohy

Potrubí může selhat po dlouhém běhu kvůli vypršení časového limitu úkolu. Časový limit úkolu silně 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í.

  • Nákup agenta hostovaného Microsoftem, který poskytuje 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ých v prostředí Microsoftu, ověřte, že je časový limit sestavy nastavený na větší hodnotu, než je maximální časový limit úlohy. Pokud to chcete zkontrolovat, podívejte se na časové limity.

Problémy se stahováním kódu

Můj pipeline má problém v kroku checkoutu

Pokud používáte checkout krok v úložišti Git Azure Repos ve vaší organizaci, které je v jiném projektu než vaše potrubí, ujistěte se, že nastavení omezit rozsah autorizace úloh na aktuální projekt je zakázáno, nebo postupujte podle kroků v identitách pro sestavování s vymezeným rozsahem a ujistěte se, že vaše potrubí 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 protokoly obsahují 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 vaše potrubí okamžitě selhává, ujistěte se, že název vašeho projektu a úložiště jsou správné v kroku Could not find a project that corresponds with the repository nebo v deklaraci zdroje úložiště.

Problémy se správou verzí Team Foundation (TFVC)

Získání zdrojů, které nestahují některé soubory

Z příkazu tf get se může v protokolu zobrazit zpráva "Všechny soubory aktuální". Ověřte, zda má integrovaná identita služby oprávnění ke stažení zdrojů. V závislosti na vybraném rozsahu autorizace na kartě Obecné v kanálu sestavení musí mít Služba sestavení kolekce projektů nebo Služba sestavení projektu oprávnění ke stažení zdrojů. 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 Team Foundation Proxy

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

Moje pipeline selhává v kroku příkazového řádku, jako je MSBUILD

Je užitečné upřesnit, zda je selhání při sestavení nebo vydání výsledkem problému se službou Azure Pipelines (agentem nebo úlohami). Selhání sestavení a vydávání mohou být způsobena externími příkazy.

Zkontrolujte protokoly pro přesný příkazový řádek spuštěný neúspěšnou úlohou. Pokus o spuštění příkazu místně z příkazového řádku může problém znovu vytvořit. 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 MSBuild ve vašem kanálu sestavení (například používáte úlohu MSBuild nebo Visual Studio Build)? 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, dalším krokem je prozkoumat problém s nástrojem 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říklad nové úložiště vytvořené pro účely řešení potíží). Jak je napsáno, skript prohledává adresáře ve vaší cestě. Můžete volitelně upravit SEARCH_PATH= řádek 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 interaktivní přihlášené relaci. Bez interaktivní přihlášené relace existují omezení pro interakci s uživatelským rozhraním a další omezení.

Chyby souborů nebo složek při použití

File or folder in use chyby jsou 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 momentální snímek lze použít nástroje jako Process Explorer nebo Handle.

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). Jinak procesy MSBuild budou nadále běžet po dokončení sestavení. Procesy zůstávají po určitou dobu v očekávání možné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 procesů nástroje 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 potíže, jako jsou problémy s přístupem k souborům při současném běhu více procesů.

Zkuste přidat /m:1 argument do úloh sestavení, aby nástroj MSBuild spustil pouze jeden proces najednou.

Problémy se současným využitím souborů mohou nastat při využívání funkce souběžných procesů 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í MSBuild nebo Visual Studio, možná budete muset zadat "/m:1", aby se přepsal argument "/m", který je přidán ve výchozím nastavení.

Přerušované nebo nekonzistentní chyby nástroje 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. Podívejte se na 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 proces vyžaduje dialogové okno pro zadání.

Spuštění agenta jako služby může pomoci zabránit tomu, aby programy vyžadovaly zadání vstupu. Například v .NET mohou programy spoléhat na Booleovskou hodnotu System.Environment.UserInteractive, aby určily, zda 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á zablokovaný proces.

Projekt WiX

Vytváření projektu WiX s povolenými vlastními loggery MSBuild může způsobit zablokování WiX, který čeká na výstupní datový proud. Přidání dalšího argumentu MSBuild /p:RunWixToolsOutOfProc=true obchází problém.

Konce řádků pro více platforem

Když spouštíte pipeline na více platformách, můžete někdy narazit na problémy s různými konci řádků. V minulosti používaly Linux a macOS znaky linefeed (LF), zatímco systém Windows používal návrat vozíku plus linefeed (CRLF). Git se snaží vyrovnat rozdíl tím, že automaticky konvertuje konce řádků na LF v úložišti a na 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řipojený apostrof

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 jste nastavili. 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ů pro Bash obsahuje příkaz set -x, který pomáhá s laděním. Bash sleduje, jaký příkaz byl spuštěn, a vypíše ho na stdout. To způsobí, že agent uvidí ##vso příkaz dvakrát a podruhé Bash přidá na konec znak '.

Představte si například tento proces:

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

Na stdoutu agent vidí 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ž však agent narazí na druhý řádek, zpracuje vše až do konce řádku. MY_VAR je nastaveno 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 requirements.txt soubor, 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ě. Pokud chcete konkrétně řešit potíže s připojeními služeb pomocí identity úloh pro ověřování, přečtěte si téma Řešení potíží s připojeními služby identit úloh.

Procesní řada přestala přijímat data od agenta

Pokud vaše pipeline 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, zda počítači agenta nedochází prostředky. Od sprintu 228protokoly 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, paměti a procesoru, pokud povolíte podrobné protokoly. Po dokončení potrubí 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ů.

Umožněte Průzkumníku služby Storage nasazovat statický obsah jako .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

  • Last updated on