Körningssekvens för pipeline

  • Artikel

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Körningar representerar en körning av en pipeline. Under en körning bearbetas pipelinen och agenterna bearbetar ett eller flera jobb. En pipelinekörning innehåller jobb, steg och uppgifter. Kör pipelines för både kontinuerlig integrering (CI) och kontinuerlig leverans (CD).

Översikt över pipeline

När du kör en pipeline händer många saker under täcket. Du behöver ofta inte känna till dem, men ibland är det bra att ha helhetsbilden. På en hög nivå kommer Azure Pipelines att:

På agentsidan för varje jobb kommer en agent att:

Jobb kan lyckas, misslyckas eller avbrytas. Det finns också situationer där ett jobb kanske inte slutförs. Att förstå hur detta händer kan hjälpa dig att felsöka problem.

Låt oss dela upp varje åtgärd en i taget.

Bearbeta pipelinen

Expandera YAML-mallar

För att omvandla en pipeline till en körning går Azure Pipelines igenom flera steg i den här ordningen:

  1. Expandera först mallar och utvärdera malluttryck.
  2. Utvärdera sedan beroenden på stegnivå för att välja de första stegen som ska köras.
  3. För varje steg som valts att köras händer två saker:
  4. För varje jobb som valts att köras expanderar du flera konfigurationer (strategy: matrix eller strategy: parallel i YAML) till flera körningsjobb.
  5. För varje körningsjobb utvärderar du villkor för att avgöra om jobbet är berättigat att köras.
  6. Begär en agent för varje kvalificerat körningsjobb.

När körningsjobben har slutförts ser Azure Pipelines om det finns nya jobb som är berättigade att köras. I så fall upprepas steg 4–6 med de nya jobben. På samma sätt upprepas steg 2–6 för alla nya steg när stegen är klara.

Den här ordningen hjälper till att besvara en vanlig fråga: varför kan jag inte använda vissa variabler i mina mallparametrar? Steg 1, mallexpansion, gäller enbart texten i YAML-dokumentet. Körningsvariabler finns inte under det steget. Efter steg 1 har mallparametrarna matchats och finns inte längre.

Det besvarar också ett annat vanligt problem: varför kan jag inte använda variabler för att lösa tjänstanslutnings-/miljönamn? Resurser auktoriseras innan en fas kan börja köras, så variabler på fas- och jobbnivå är inte tillgängliga. Variabler på pipelinenivå kan användas, men endast de variabler som uttryckligen ingår i pipelinen. Variabelgrupper är själva en resurs som omfattas av auktorisering, så deras data är inte heller tillgängliga när du kontrollerar resursauktorisering.

Begära en agent

När Azure Pipelines behöver köra ett jobb kommer den att be poolen om en agent. (Serverjobb är ett undantag eftersom de körs på själva Azure Pipelines-servern.) Microsofts värdbaserade och lokalt installerade agentpooler fungerar lite annorlunda.

Begäranden om Microsoft-värdbaserad agentpool

Först kontrollerar tjänsten organisationens parallella jobb. Den summerar alla jobb som körs på alla Microsoft-värdbaserade agenter och jämför det med antalet parallella jobb som köpts. Om det inte finns några tillgängliga parallella platser måste jobbet vänta på en plats för att frigöra sig.

När ett parallellt fack är tillgängligt dirigeras jobbet till den begärda agenttypen. Konceptuellt är den Microsoft-värdbaserade poolen en gigantisk, global pool av datorer. (I verkligheten är det många olika fysiska pooler uppdelade efter geografi och typ av operativsystem.) Baserat på det vmImage (i YAML) eller poolnamnet (i den klassiska redigeraren) som begärdes väljs en agent.

Val av pool

Alla agenter i Microsoft-poolen är nya, nya virtuella datorer som inte har kört några pipelines tidigare. När jobbet har slutförts ignoreras den virtuella agentdatorn.

Begäranden om lokalt installerad agentpool

Precis som i den Microsoft-värdbaserade poolen kontrollerar tjänsten först organisationens parallella jobb. Den summerar alla jobb som körs på alla lokalt installerade agenter och jämför det med antalet parallella jobb som köpts. Om det inte finns några tillgängliga parallella platser måste jobbet vänta på en plats för att frigöra sig.

När en parallell plats är tillgänglig granskas den lokala poolen för en kompatibel agent. Lokalt installerade agenter erbjuder funktioner, som är strängar som anger att viss programvara är installerad eller att inställningar har konfigurerats. Pipelinen har krav, som är de funktioner som krävs för att köra jobbet. Om en kostnadsfri agent vars funktioner matchar pipelinens krav inte kan hittas fortsätter jobbet att vänta. Om det inte finns några agenter i poolen vars funktioner matchar kraven misslyckas jobbet.

Lokalt installerade agenter återanvänds vanligtvis från körning till körning. För lokalt installerade agenter kan ett pipelinejobb ha sidoeffekter som att värma upp cacheminnen eller att de flesta incheckningar redan är tillgängliga på den lokala lagringsplatsen.

Förbereda för att köra ett jobb

När en agent har accepterat ett jobb har den en del förberedelsearbete att utföra. Agenten laddar ned (och cachelagrar för nästa gång) alla uppgifter som behövs för att köra jobbet. Det skapar arbetsutrymme på disken för att lagra källkoden, artefakterna och utdata som används i körningen. Sedan börjar den köra steg.

Kör varje steg

Stegen körs sekventiellt, en efter en. Innan ett steg kan starta måste alla föregående steg vara slutförda (eller hoppas över).

Kör varje uppgift

Stegen implementeras av uppgifter. Själva uppgifterna implementeras som Node.js- eller PowerShell-skript. Uppgiftssystemet dirigerar indata och utdata till stödskripten. Den innehåller också några vanliga tjänster, till exempel att ändra systemsökvägen och skapa nya pipelinevariabler.

Varje steg körs i sin egen process och isolerar det från miljön som lämnades av föregående steg. På grund av den här modellen för process-per-steg bevaras inte miljövariabler mellan stegen. Uppgifter och skript har dock en mekanism för att kommunicera tillbaka till agenten: loggningskommandon. När en uppgift eller ett skript skriver ett loggningskommando till standard ut, vidtar agenten den åtgärd som begärs.

Det finns ett agentkommando för att skapa nya pipelinevariabler. Pipelinevariabler konverteras automatiskt till miljövariabler i nästa steg. För att ange en ny variabel myVar med värdet myValuekan ett skript göra detta:

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Rapportera och samla in resultat

Varje steg kan rapportera varningar, fel och fel. Fel och varningar rapporteras till sammanfattningssidan för pipelinen, vilket markerar uppgiften som "lyckades med problem". Fel rapporteras också till sammanfattningssidan, men de markerar uppgiften som "misslyckad". Ett steg är ett fel om det antingen uttryckligen rapporterar fel (med ett ##vso kommando) eller avslutar skriptet med en slutkod som inte är noll.

Loggar och resultat flödar från agent till tjänst

När stegen körs skickar agenten hela tiden utdatarader till tjänsten. Det är därför du kan se en live-feed för konsolen. I slutet av varje steg laddas även hela utdata från steget upp som en loggfil. Loggar kan laddas ned när pipelinen är klar. Andra objekt som agenten kan ladda upp är artefakter och testresultat. Dessa är också tillgängliga när pipelinen har slutförts.

Tillstånd och villkor

Agenten håller reda på varje stegs framgång eller misslyckande. När stegen lyckas med problem eller misslyckas uppdateras jobbets status. Jobbet visar alltid det "sämsta" resultatet från vart och ett av stegen: om ett steg misslyckas misslyckas även jobbet.

Innan du kör ett steg kontrollerar agenten det stegets villkor för att avgöra om det ska köras. Som standard körs ett steg bara när jobbets status har slutförts eller har lyckats med problem. Många jobb har rensningssteg som måste köras oavsett vad som hände, så att de kan ange villkoret "always()". Rensningssteg kan också vara inställda på att endast köras vid annullering. Ett efterföljande rensningssteg kan inte spara jobbet från att misslyckas. jobb kan aldrig återgå till framgång efter att ha hamnat i fel.

Timeouter och frånkopplingar

Varje jobb har en tidsgräns. Om jobbet inte har slutförts under den angivna tiden avbryter servern jobbet. Den försöker signalera att agenten ska stoppas, och jobbet markeras som avbrutet. På agentsidan innebär det att alla återstående steg avbryts och eventuella återstående resultat laddas upp.

Jobben har en respitperiod som kallas för tidsgränsen för att avbryta arbetet. (Kom ihåg att steg kan markeras för att köras även vid annullering.) Om agenten inte har rapporterat att arbetet har stoppats efter tidsgränsen plus tidsgränsen för avbruten markerar servern jobbet som ett fel.

Eftersom Azure Pipelines distribuerar arbete till agentdatorer kan agenter då och då sluta svara på servern. Detta kan inträffa om agentens värddator försvinner (strömavbrott, avstängd virtuell dator) eller om det uppstår ett nätverksfel. För att identifiera dessa villkor skickar agenten ett pulsslagsmeddelande en gång per minut för att meddela servern att den fortfarande fungerar. Om servern inte får pulsslag fem minuter i följd förutsätter det att agenten inte kommer tillbaka. Jobbet markeras som ett fel så att användaren vet att de ska försöka utföra pipelinen igen.

Hantera körningar via CLI

Med Hjälp av Azure DevOps CLI kan du lista pipelinekörningarna i projektet och visa information om en specifik körning. Du kan också lägga till och ta bort taggar i pipelinekörningen.

Förutsättningar

  • Du måste ha installerat Azure DevOps CLI-tillägget enligt beskrivningen i Kom igång med Azure DevOps CLI.
  • Logga in på Azure DevOps med .az login
  • I exemplen i den här artikeln anger du standardorganisationen med hjälp av az devops configure --defaults organization=YourOrganizationURL.

Lista pipelinekörningar

Visa en lista över pipelinekörningar i projektet med kommandot az pipelines runs list . Kom igång genom att läsa Kom igång med Azure DevOps CLI.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Valfria parametrar

  • branch: Filtrera efter versioner för den här grenen.
  • org: Url för Azure DevOps-organisation. Du kan konfigurera standardorganisationen med hjälp av az devops configure -d organization=ORG_URL. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config. Exempel: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: Utrymmesavgränsade ID:t för definitioner som byggena ska listas för.
  • project: Projektets namn eller ID. Du kan konfigurera standardprojektet med hjälp av az devops configure -d project=NAME_OR_ID. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config.
  • query-order: Definiera i vilken ordning pipelinekörningar visas. Godkända värden är FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc och StartTimeDesc.
  • orsak: Endast listversioner av den här angivna orsaken. Godkända värden är batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated och validateShelveset.
  • requested-for: Begränsa till de versioner som begärs för en angiven användare eller grupp.
  • result: Begränsa till versionerna med ett angivet resultat. Godkända värden avbryts, misslyckas, ingen, delvisucceeded ochlyckas.
  • status: Begränsa till byggen med angiven status. Godkända värden är alla, avbryter, slutförs, inProgress, none, notStarted och postponed.
  • tags: Begränsa till versionerna med var och en av de angivna taggarna. Blanksteg avgränsat.
  • överst: Maximalt antal byggen som ska listas.

Exempel

Följande kommando visar de tre första pipelinekörningarna som har statusen slutförd och resultatet lyckades och returnerar resultatet i tabellformat.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Visa information om pipelinekörning

Visa information om en pipelinekörning i projektet med kommandot az pipelines runs show . Kom igång genom att läsa Kom igång med Azure DevOps CLI.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parametrar

  • id: Krävs. ID för pipelinekörningen.
  • open: Valfritt. Öppnar sidan med byggresultat i webbläsaren.
  • org: Url för Azure DevOps-organisation. Du kan konfigurera standardorganisationen med hjälp av az devops configure -d organization=ORG_URL. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config. Exempel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Projektets namn eller ID. Du kan konfigurera standardprojektet med hjälp av az devops configure -d project=NAME_OR_ID. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config.

Exempel

Följande kommando visar information om pipelinekörningen med ID 123 och returnerar resultatet i tabellformat. Webbläsaren öppnas också på sidan med byggresultat.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Lägg till tagg i pipelinekörning

Lägg till en tagg i en pipelinekörning i projektet med kommandot az pipelines runs tag add . Kom igång genom att läsa Kom igång med Azure DevOps CLI.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parametrar

  • run-id: Krävs. ID för pipelinekörningen.
  • tags: Krävs. Taggar som ska läggas till i pipelinekörningen (kommaavgränsade värden).
  • org: Url för Azure DevOps-organisation. Du kan konfigurera standardorganisationen med hjälp av az devops configure -d organization=ORG_URL. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config. Exempel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Projektets namn eller ID. Du kan konfigurera standardprojektet med hjälp av az devops configure -d project=NAME_OR_ID. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config.

Exempel

Följande kommando lägger till taggen YAML i pipelinekörningen med ID 123 och returnerar resultatet i JSON-format.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Lista pipelinekörningstaggar

Lista taggarna för en pipelinekörning i projektet med kommandot az pipelines runs tag list . Kom igång genom att läsa Kom igång med Azure DevOps CLI.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parametrar

  • run-id: Krävs. ID för pipelinekörningen.
  • org: Url för Azure DevOps-organisation. Du kan konfigurera standardorganisationen med hjälp av az devops configure -d organization=ORG_URL. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config. Exempel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Projektets namn eller ID. Du kan konfigurera standardprojektet med hjälp av az devops configure -d project=NAME_OR_ID. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config.

Exempel

Följande kommando visar taggarna för pipelinekörningen med ID 123 och returnerar resultatet i tabellformat.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Ta bort tagg från pipelinekörning

Ta bort en tagg från en pipelinekörning i projektet med kommandot az pipelines runs tag delete . Kom igång genom att läsa Kom igång med Azure DevOps CLI.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parametrar

  • run-id: Krävs. ID för pipelinekörningen.
  • tag: Krävs. Tagg som ska tas bort från pipelinekörningen.
  • org: Url för Azure DevOps-organisation. Du kan konfigurera standardorganisationen med hjälp av az devops configure -d organization=ORG_URL. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config. Exempel: --org https://dev.azure.com/MyOrganizationName/.
  • project: Projektets namn eller ID. Du kan konfigurera standardprojektet med hjälp av az devops configure -d project=NAME_OR_ID. Krävs om det inte är konfigurerat som standard eller hämtas med hjälp av git config.

Exempel

Följande kommando tar bort YAML-taggen från pipelinekörningen med ID 123.

az pipelines runs tag delete --run-id 123 --tag YAML