Ladění hostovaného agenta

Diagnostikujte a opravujte běžné problémy při sestavování, spouštění a nasazování agentů azd ai agent pro Microsoft Foundry. Začněte s diagnostickými příkazy. Pak pomocí oddílů podle příznaků řešte problémy s autentizací, místním vývojem, nasazením, přímými příkazy, logy a rutinami.

Předpoklady

  • Inicializovaný projekt hostovaného agenta. Pokud ho chcete vytvořit, přečtěte si téma Inicializace projektu agenta.
  • Nainstalované rozšíření azd Foundry. Postup instalace najdete v tématu Instalace rozšíření azd Foundry.
  • Autentizovaná relace Azure Developer CLI. V případě potřeby spusťte azd auth login .
  • V případě problémů s nasazením a protokolem je nasazený hostovaný agent. Pokud ho chcete nasadit, přečtěte si téma Nasazení hostovaného agenta.

Shromáždit diagnostické informace

Než se ponoříte do konkrétních chyb, shromážděte kontext pomocí těchto příkazů:

# Check extension version
azd ai agent version

# Verify Azure authentication
azd auth login

# Show current environment configuration
azd env get-values

# View agent details
azd ai agent show

# Show the resolved Foundry project endpoint and where it came from
azd ai project show

# Stream production logs
azd ai agent monitor --follow

Pro získání strukturované sestavy o stavu spusťte azd ai agent doctor. Další informace najdete v tématu Diagnostika projektu pomocí nástroje Agent Doctor.

Diagnostikujte latenci vyvolání

Pomocí ladicích hlaviček latence určete, zda pomalý požadavek na hostovaného agenta strávil čas v platformě, při zřizování infrastruktury, čekáním na kontejner nebo zpracováním požadavku ve vašem agentovi. Tyto hlavičky jsou diagnostické signály, nikoli metriky SLA nebo fakturace.

Povolte diagnostiku u každého požadavku nastavením x-ms-debug-latency-enabled: true. Pokud požadavek neobsahuje tuto hlavičku, odpověď nebude obsahovat x-ms-debug-latency-* hlavičky.

  1. Přidejte hlavičku latence do požadavku protokolu Responses nebo Invocations pro hostovaného agenta. V tomto příkladu se používá protokol Odpovědi:

    ENDPOINT="https://{account}.services.ai.azure.com/api/projects/{project}"
API_VERSION="v1"
TOKEN=$(az account get-access-token \
  --resource https://ai.azure.com \
  --query accessToken -o tsv)
AGENT="my-code-agent"

curl --http2 -i -X POST \
  "$ENDPOINT/agents/$AGENT/endpoint/protocols/openai/responses?api-version=$API_VERSION" \
  -H "Authorization: Bearer $TOKEN" \
  -H "Content-Type: application/json" \
  -H "x-ms-debug-latency-enabled: true" \
  -d '{"model":"gpt-5.4-mini","input":"Hello, agent!","stream":false}'

  2. Zkontrolujte hlavičky odpovědi. Všechny hodnoty latence jsou celočíselné milisekundy:

    Header Meaning
    x-ms-debug-latency-session-start-type Typ spuštění relace, který požadavek vyvolal: studený start (cold), teplý start (warm) nebo obnovení z nečinnosti (resume).
    x-ms-debug-latency-platform-preprocessing-ms Čas platformy pro přístup, ověřování, vyhledávání relací a orchestraci Nezahrnuje zpoždění zřizování mikro-virtuálních počítačů ani připravenosti kontejnerů. K dispozici pro spuštění studené, teplé a obnovené relace.
    x-ms-debug-latency-infra-setup-ms Doba potřebná ke zřízení mikro-VM. Pro teplé žádosti se vynechá.
    x-ms-debug-latency-container-readiness-ms Doba od vytvoření mikro‑VM do okamžiku, kdy kontejner ohlásí připravenost. Vynecháno pro teplé požadavky.
    x-ms-debug-latency-container-response-ms Doba od přeposlání proxy serverem do potvrzení hlaviček odpovědi. Zahrnuje přenos požadavku, nastavení připojení, obsluhu agenta, opakované pokusy a bufferování zásad výstupu.
    x-ms-debug-latency-response-begin-ms Celková doba od přijetí služby do potvrzení hlaviček odpovědi. Tato hodnota nepředstavuje čas do přijetí prvního bajtu těla odpovědi ani první serverem zaslané události.

    Čtyři komponenty časování se sčítají do x-ms-debug-latency-response-begin-ms. Při požadavku typu cold start nebo při obnoveném požadavku platí, že pokud platforma nedokáže zachytit všechny hranice procesu provisioningu, vynechá hlavičky infrastruktury a připravenosti a započítá tento čas do předzpracování platformy.

  3. K identifikaci pravděpodobného zdroje zpoždění použijte typ spuštění relace a největší komponentu časování:

    Result Výklad Co dělat
    x-ms-debug-latency-session-start-type je cold nebo resume a x-ms-debug-latency-infra-setup-ms je vysoká Platformě nějakou dobu trvalo vytvoření mikrovirtuálního stroje. Porovnejte několik nových nebo obnovených požadavků. Pokud zpoždění přetrvává, poznamenejte si ID odpovědi, časové razítko a hlavičky latence pro žádost o podporu.
    x-ms-debug-latency-session-start-type je cold nebo resume a x-ms-debug-latency-container-readiness-ms je vysoká Kontejneru trvalo dlouho, než se spustil a nahlásil připravenost. Změřte kroky inicializace v spouštěcích protokolech, omezte práci před zpřístupněním koncového bodu připravenosti a kód aplikace předkompilujte tam, kde je to možné.
    x-ms-debug-latency-platform-preprocessing-ms je vysoká u všech typů spuštění relace. Ke zpoždění došlo na platformě před zřizováním micro-VM nebo připraveností kontejnerů. Vytvořte žádost o podporu. Uveďte ID odpovědi, časové razítko, typ zahájení relace a hlavičky latence.
    x-ms-debug-latency-container-response-ms, x-ms-debug-latency-first-byte-msnebo přívěs je first_byte_ms vysoký Ke zpoždění došlo poté, co začalo přeposílání přes proxy. Instrumentujte obslužnou rutinu požadavku a zkontrolujte protokoly agenta, volání modelu, volání nástrojů, opakování a ukládání výstupu do vyrovnávací paměti.

Zkrácení doby připravenosti kontejneru

Hodnota připravenosti kontejneru zahrnuje čas potřebný ke spuštění procesu, načtení aplikace a vrácení protokolu HTTP 200 z /readiness. Přidejte do spouštěcích protokolů časová razítka pro identifikaci pomalých importů, načítání závislostí, síťových volání a dalších inicializačních prací.

Tyto optimalizace použijte u pomalých kroků, které identifikujete:

  • Při sestavování image nainstalujte závislosti a zkompilujte kód. Při spuštění kontejneru nespustí instalaci, obnovení nebo kompilaci balíčku.
  • Použijte vícefázové sestavení a z runtime image vylučte nástroje pro sestavení, mezipaměti balíčků, testy a další vývojové soubory.
  • Vyhněte se volání modelů, migracím, zjišťování nástrojů a stahování prostředků před připraveností. Paralelizujte nezávislé inicializační úlohy, které musí být dokončeny jako první.
  • Zaměřte /readiness se na to, jestli agent může přijímat žádosti. Pokud odložíte inicializaci, změřte první požadavek, abyste se ujistili, že jste nepřesunuli zpoždění spuštění do zpracování požadavků.

Nainstalujte závislosti do virtuálního prostředí, které zkopírujete do image pro běhové prostředí. Kompilujte závislosti podle možností, aby soubor v balíčku třetí strany, který nelze analyzovat, nezpůsobil selhání sestavení. Zkompilujte aplikaci striktně, aby chyby syntaxe způsobily selhání sestavení.

FROM python:3.13-slim AS build

WORKDIR /app
RUN python -m venv /opt/venv
ENV PATH="/opt/venv/bin:$PATH"

COPY requirements.txt .
RUN pip install --no-cache-dir -r requirements.txt

COPY . .
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q /opt/venv \
      || true; \
    PYTHONDONTWRITEBYTECODE= python -m compileall -q /app

FROM python:3.13-slim AS final

ENV PATH="/opt/venv/bin:$PATH"
WORKDIR /app

COPY --from=build /opt/venv /opt/venv
COPY --from=build /app /app

# Precompile the standard library in the runtime image.
RUN PYTHONDONTWRITEBYTECODE= python -m compileall -q \
    "$(python -c "import sysconfig; print(sysconfig.get_path('stdlib'))")" \
    || true

CMD ["python", "main.py"]

Vymazání PYTHONDONTWRITEBYTECODE tohoto kroku sestavení umožňuje Python zápis bajtového kódu do image. Proměnná prostředí blokuje zápisy bajtového kódu, nikoli čtení, takže spuštěný kontejner může stále používat kompilované soubory.

Referenční informace: compileall – zkompilovat knihovny Pythonu do bajtového kódu

Vytvořte jednu z imagí pro architekturu x86-64 vyžadovanou hostovanými agenty:

docker build --platform linux/amd64 -t my-agent:latest .

Zde je linux/amd64 platforma Docker, nikoli identifikátor modulu runtime pro .NET.

Referenční informace: Požadavky na kontejner hostovaného agenta

Zkoumání latence agenta a modelu

Pokud je připravenost kontejneru rychlá, ale odezva kontejneru nebo doba prvního bajtu je vysoká, zaměřte se na cestu požadavku po zahájení předávání. Spusťte azd ai agent monitor --follow během reprodukce požadavku a přidejte trasování pro volání modelu, volání nástrojů, externí služby, opakované pokusy a serializaci odpovědí. Další informace najdete v tématu Monitorování protokolů hostovaného agenta.

U agenta, který volá velký jazykový model, změřte latenci modelu samostatně před změnou nasazení. Porovnejte čas s prvním tokenem, časem mezi tokeny, vygenerovaným počtem tokenů, velikostí výzvy, využitím nasazení a omezováním. Pak vyhodnoťte výběr modelu, limity výstupních tokenů, streamování a oddělení úloh. Viz Zlepšení výkonu Azure OpenAI.

Pokud měření ukazují trvalý tlak na kapacitu pro předvídatelnou úlohu, vyhodnoťte zřízené nasazení a jeho velikost pro pozorované vstupní tokeny, výstupní tokeny a rychlost požadavků. Viz Zřízená propustnost.

Kontrola časování dokončení

V protokolu HTTP/2 nebo novějším může služba vrátit trailer odpovědi x-ms-debug-latency-final v režimu best-effort. Zopakuje hodnoty hlavičky odpovědi a může přidat tato pole:

Pole Meaning
first_byte_ms Doba od přijetí požadavku službou do přijetí prvního bajtu těla odpovědi nebo serverem odeslané události.
total_last_byte_ms Doba od přijetí služby do dokončení předávání odpovědí.

Přívěs používá formát oddělený středníkem:

x-ms-debug-latency-final: v=1;start=cold;platform_pre_ms=...;
  infra_ms=...;ready_ms=...;container_response_ms=...;
  response_begin_ms=...;first_byte_ms=...;total_last_byte_ms=...

Odpovědi HTTP/1.1 nezahrnují tento přívěs. Přívěs může také chybět po zrušení, odpojení klienta, uprostředstreamové chybě nebo v případě, že brána nebo sada SDK nezachovávají přívěsy. Zacházejte s hlavičkami odpovědi jako se zaručenou diagnostickou smlouvou.

Načtení uložených výsledků latence

Služba ukládá zachycené časové údaje spolu s odpovědí nebo voláním. Pozdější požadavek GET pro stejnou odpověď nebo ID vyvolání vrátí časování původního požadavku jako hlavičky odpovědi. Požadavek GET nevyžaduje hlavičku latency a neměří dobu trvání samotného požadavku GET.

Požadavek GET může také vrátit tyto hodnoty dokončení jako běžné hlavičky:

Header Meaning
x-ms-debug-latency-first-byte-ms Čas na první bajt textu odpovědi
x-ms-debug-latency-total-last-byte-ms Doba do dokončení přeposílání odpovědi

Úložiště je nakonec konzistentní, takže požadavek GET hned po původním požadavku ještě nemusí obsahovat hlavičky. Pro asynchronní odpověď nebo volání jsou k dispozici pouze hodnoty režie platformy: typ spuštění relace, předzpracování platformy, nastavení infrastruktury a připravenost kontejneru. Hlavičky latence se neodesílají pro neúspěšné odpovědi proxy serveru ani pro požadavky WebSocket (invocations_ws).

Oprava chyb ověřování

Opravit AuthenticationError

Příznaky: Agent se nespustí místně nebo při volání modelu AI vrátí hodnotu 401/403.

Příčiny a opravy:

  • Platnost přihlašovacích údajů vypršela – Spusťte azd auth login, aby se obnovila vaše relace Azure.
  • Nesprávné předplatné – Ověřte a porovnejte azd env get-values | grep AZURE_SUBSCRIPTION_ID ho s předplatným projektu Foundry.
  • Chybějící role RBAC – Vaše identita potřebuje uživatele Foundry nebo ekvivalentní přístup k projektu Foundry.

Important

Nedávno byly přejmenovány role Foundry RBAC. Foundry User, Foundry Owner, Foundry Account Owner a Foundry Project Manager se dříve nazývaly Uživatel Azure AI, Vlastník Azure AI, Vlastník účtu Azure AI a Správce projektů Azure AI. Během zavádění přejmenování se stále můžou zobrazovat předchozí názvy na některých místech. ID rolí a základní oprávnění se při přejmenování nezmění.

Vaše identita také potřebuje roli Cognitive Services OpenAI User, aby mohla používat nasazení modelů.

Opravit AuthorizationFailed během nasazování

Příznaky:azd up nebo azd provision selže s chybou oprávnění.

Opravit: V předplatném Azure požádejte o roli Přispěvatel. Pro CI/CD potřebuje instanční objekt služby také Foundry Owner.

Opravit SubscriptionNotRegistered

Příznaky: Nasazení selže, protože požadovaný poskytovatel prostředků není zaregistrován.

Oprava:

az provider register --namespace Microsoft.CognitiveServices
az provider register --namespace Microsoft.ContainerRegistry

Řešení místních problémů s vývojem

Opravte odmítnuté připojení na portu 8088

Příznaky:azd ai agent invoke --local připojení se nezdaří.

Příčiny a opravy:

  • Agent není spuštěný – Spusťte ho azd ai agent run v samostatném terminálu.

  • Konflikt portů – Jiný proces používá port 8088. Buď ho zastavte, nebo použijte vlastní port:

    azd ai agent run --port 9090
azd ai agent invoke --local --port 9090 "Hello!"

  • Chyba při spuštění -- Zkontrolujte chybový výstup v terminálu, ve kterém je spuštěný azd ai agent run. Mezi běžné příčiny patří chybějící závislosti, chyby importu nebo nesprávné startupCommand v souboru azure.yaml.

Opravte selhání při instalaci závislostí

Příznaky:azd ai agent run selže během instalace závislostí.

Příčiny a opravy:

  • Nesprávná verze modulu runtime – Ujistěte se, že je nainstalovaná Python verze 3.10 nebo .NET 8 nebo novější.
  • Chybí requirements.txt nebo .csproj – rozhraní příkazového řádku automaticky rozpozná typ projektu z těchto souborů. Ověřte, že existují v adresáři agenta.
  • Problémy se sítí – Vaše firemní proxy server může blokovat registry balíčků. Zkontrolujte svoji pip nebo dotnet konfiguraci.

Opravte ResourceNotFound nebo DeploymentNotFound

Příznaky: Agent se spustí, ale při pokusu o volání modelu selže.

Příčiny a opravy:

  • Neshoda koncových bodů – Spusťte azd env get-values a ověřte, že FOUNDRY_PROJECT_ENDPOINT odpovídá koncovému bodu zobrazenému na portálu Foundry.
  • Neshoda názvů nasazení modelu -- Název nasazení modelu nakonfigurovaný v azure.yaml se musí shodovat s názvem nasazení ve vašem projektu Foundry. V portálu se podívejte do části Nasazení.
  • Prostředky nebyly zřízeny -- Pokud jste ještě nespustili azd up, cloudové prostředky nebudou existovat. Nejprve spusťte a pak místně otestujte azd up . Místní agent stále volá modely hostované v cloudu.

Řešení problémů s nasazením

Opravte selhání při sestavení kontejneru

Příznaky:azd up selže během fáze sestavení Dockeru.

Příčiny a opravy:

  • Chybí soubor Dockerfile – Ujistěte se, že váš adresář agenta obsahuje Dockerfile. Pokud jste inicializovali ze šablony, automaticky se vygeneruje.
  • Chyby kontextu sestavení – Dockerfile musí být v adresáři určeném cestou služby project v souboru azure.yaml.
  • Instalace závislostí v Dockeru -- Pokud příkaz `pip`/`dotnet restore` uvnitř kontejneru selže, zkontrolujte, zda má requirements.txt nebo .csproj správně připnuté všechny závislosti.

Opravit azd up zaseknutí nebo vypršení časového limitu

Příznaky: Zřizování nebo nasazení trvá neobvykle dlouho.

Příčiny a opravy:

  • První nasazení – první azd up zřídí všechny prostředky Azure, včetně projektu Foundry, ACR, spravované identity a nasazení modelu, a může trvat 5 až 10 minut. Další nasazení jsou rychlejší.
  • Vzdálené sestavení – Ve výchozím nastavení se image kontejnerů vytvářejí vzdáleně v ACR. To může být pomalejší, ale nevyžaduje Docker místně. Pokud chcete místo toho sestavit místně, nastavte docker.remoteBuild: false v azure.yaml konfiguraci služby.
  • Kapacita oblasti – Některé oblasti můžou mít omezenou kapacitu pro určité skladové položky modelu. Pokud zřizování konzistentně selže, zkuste jinou oblast.

Opravte agenta, který se nasadí, ale nereaguje

Příznaky:azd ai agent invoke po úspěšném nasazení dochází k vypršení časového limitu nebo se vracejí chyby.

Příčiny a opravy:

  • Kontrola stavu selhala -- Váš kontejner musí reagovat na GET /readiness na portu 8088 se stavovým kódem 200. Zkontrolujte protokoly pomocí azd ai agent monitor --follow.
  • Neshoda protokolu – Ujistěte se, že protokol definovaný ve službě azure.ai.agentazure.yaml odpovídá tomu, co váš kód implementuje. Pokud azure.yaml uvádí responses, ale váš kód zpracovává pouze invocations, nebo naopak, požadavky selžou.
  • Selhání kontejneru -- Zkontrolujte systémové protokoly a vyhledejte události restartování: azd ai agent monitor --type system. Mezi běžné příčiny patří neošetřené výjimky a problémy s nedostatkem paměti. V případě potřeby navyšte prostředky kontejneru azure.yaml.

Oprava selhání přímého příkazu

Tyto chyby pocházejí z přímých příkazů azd ai, jako jsou azd ai connection, azd ai toolbox a azd ai routine, při spuštění nad projektem Foundry.

Oprava koncového bodu nevyřešeného projektu Foundry

Příznaky: Přímý příkaz se ukončí pomocí příkazu No Foundry project endpoint resolved. Run azd ai project set to set one, or pass --project-endpoint.

Příčina: CLI nemohlo najít koncový bod projektu Foundry v žádném z podporovaných zdrojů: v přepínači --project-endpoint, v aktivním prostředí azd, v globální konfiguraci nebo v proměnné prostředí FOUNDRY_PROJECT_ENDPOINT.

Opravy:

  • Spusťte azd ai project set <endpoint>, chcete-li uložit endpoint do své globální konfigurace azd (~/.azd/config.json).
  • Předejte --project-endpoint (-p) u každého příkazu: azd ai connection list -p https://my-proj.services.ai.azure.com/api/projects/my-project.
  • Nastavte FOUNDRY_PROJECT_ENDPOINT v prostředí shellu.

Úplné pořadí řešení a čas, kdy každý zdroj vyhrává, najdete v tématu Vysvětlení kontextu projektu azd.

Opravit selhání při vytváření již existujících prostředků

Příznaky:azd ai connection create, azd ai toolbox create, azd ai routine createnebo azd ai skill create selže s chybou "již existuje".

Příčina: U create není operace upsert záměrně podporována. Výchozí režim selhání brání jednomu vývojáři v tichém přepsání stavu jiného ve sdíleném projektu Foundry.

Opravy:

  • Vyberte jiný název a spusťte ho znovu.
  • Předejte --force, pokud to příkaz create podporuje, a nahraďte stávající prostředek pomocí operace ARM PUT. Nahrazení je destruktivní: přepíše existující prostředek přímo na místě a ztratí se jakékoli odchylky vzniklé ručními úpravami v portálu, metadaty nebo přihlašovacími údaji. Příkaz azd ai toolbox create nepodporuje --force. Odstraňte existující sadu nástrojů nebo místo toho použijte nový název.

Oprava connection show výstupu přihlašovacích údajů

Příznaky:azd ai connection show <name> vrátí název připojení, druh, cíl a typ ověřování, ale bez klíče rozhraní API nebo hodnoty přihlašovacích údajů.

Příčina: Hodnoty přihlašovacích údajů se z podstaty návrhu ve výchozím nastavení nikdy nevracejí. Vyžadují explicitní příznak --show-credentials.

Oprava:

azd ai connection show tavily-conn --show-credentials

Tím se volá rozhraní API datové roviny a vyžaduje oprávnění pro datovou rovinu v projektu Foundry, například Foundry User nebo ekvivalentní oprávnění. Pokud máte přístup pouze k rovině pro správu Reader nebo Contributor, volání selže s chybou 403. Požádejte vlastníka projektu o roli roviny dat.

Čtení protokolů agenta

Slouží azd ai agent monitor ke kontrole chování agenta:

# Stream all recent logs
azd ai agent monitor --follow

# View system-level events (container starts, crashes, restarts)
azd ai agent monitor --type system

# Filter to a specific session
azd ai agent monitor --session-id <session-id>

Mezi běžné vzory protokolů patří:

Zpráva protokolu Meaning
Listening on 0.0.0.0:8088 Agent se úspěšně spustil.
AuthenticationError Problém s přihlašovacími údaji nebo s RBAC. Zkontrolujte spravovanou identitu.
ModelNotFound Název nasazení modelu se neshoduje s azure.yaml.
Restartování kontejneru v systémových událostech Cyklus pádů Zkontrolujte chyby kódu nebo zvyšte limity prostředků.

Diagnostika rutinních selhání

Rutiny selhávají odlišně než interaktivní volání agent invoke, protože není přítomen žádný volající, který by chybu zobrazil. Rutina je spuštění agenta aktivované časovačem, opakované, aktivované issuem na GitHubu nebo aktivované vlastní událostí. Slouží azd ai routine run list ke kontrole toho, co se stalo.

Zkontrolujte předchozí běhy

# Recent runs of a routine: trigger time, agent input/output, status, trace link
azd ai routine run list daily-digest

Filtrování podle selhání

# Failed runs only, with an OData filter
azd ai routine run list daily-digest --filter "status eq 'failed'"

V kombinaci s --top okno rozšíříte nebo zúžíte.

Přejít na detail jednoho spuštění

# Full detail for the most recent runs as JSON, then look up the run you care about
azd ai routine run list daily-digest --top 5 --output json

Výstup JSON zahrnuje vstupní payload, odpověď agenta a hluboký odkaz na distribuované trasování, tedy stejné trasování, jaké byste viděli při interaktivním vyvolání.

Ručně znovu spustit rutinu

Pokud potřebujete reprodukovat selhání nebo otestovat opravu, spusťte rutinu na vyžádání:dispatch

azd ai routine dispatch daily-digest
azd ai routine dispatch triage-issues --input '{"issue":{"number":42}}'

dispatch spustí asynchronně a vytiskne ID odeslání. Zkontrolujte výsledek pomocí azd ai routine run list <name>funkce .

Oprava neúspěšného spuštění rutiny

azd ai routine run list zobrazuje běh s status: failed. Kliknutím na odkaz trasování zobrazíte podkladovou chybu agenta, například chybu modelu, selhání nástroje nebo vypršení časového limitu. Opravy na straně agenta jsou stejné jako u interaktivních selhání. Viz Oprava chyb ověřování a čtení protokolů agenta.

Oprava rutiny, která se nikdy neaktivuje

Pokud azd ai routine run list nevrací vůbec žádná spuštění, samotný trigger se nespouští:

  1. Zkontrolujte, jestli je povolená rutina: azd ai routine show <name>. Vyhledejte enabled: true.
  2. U aktivačních událostí timer ověřte, že --at je v budoucnu a dosud se nespustilo.
  3. U aktivačních událostí recurring ověřte, že je výraz --cron platný a že --time-zone odpovídá tomu, co jste očekávali.
  4. U triggerů github-issue ověřte, že --connection-id odkazuje na funkční připojení a že repozitář GitHubu a --issue-event odpovídají událostem, které repozitář generuje.
  5. U triggerů custom ověřte, zda rozsah --provider, --event-name a --parameters odpovídá událostem, které poskytovatel publikuje.

Získat další nápovědu

  • Režim ladění -- Přidejte --debug k libovolnému příkazu azd pro podrobný výstup.
  • Portál Azure -- Zkontrolujte projekt Foundry na portálu Azure, kde najdete stav prostředků a diagnostické informace.
  • Zahlaste chybu – Nahlašte problémy na github.com/Azure/azure-dev/issues.

Související obsah

  • Poslední aktualizace v