Uppgiftstyper och användning

I YAML anger du huvudversionen med hjälp @ av i uppgiftsnamnet. Om du till exempel vill använda version 2 av PublishTestResults uppgiften anger du PublishTestResults@2. Du kan ange vilken delversion som ska användas genom att ange det fullständiga uppgiftsversionsnumret efter @, till exempel GoTool@0.3.1.

I klassiska pipelines har varje uppgift en versionsväljare så att du kan välja den version du vill ha. Överväg att klona pipelinen och testa den klonade pipelinen med nya huvuduppgiftsversioner. Om du väljer en förhandsversion, till exempel 1.* Förhandsversion, är versionen fortfarande under utveckling och kan ha problem.

Om du ändrar versionen och har problem med dina versioner kan du återställa pipelineändringen från fliken Historik . För versionspipelines är möjligheten att återställa till en äldre version inte tillgänglig. Du måste återställa ändringarna i versionspipelinen manuellt och sedan spara pipelinen.

Följande egenskaper är tillgängliga för YAML-pipelinesteg task . Mer information finns i definitionen steps.task .

Villkor

En uppgift kan inte avgöra om pipelinejobbet ska fortsätta när aktiviteten har slutförts, utan endast ange en slutstatus som succeeded eller failed. Underordnade aktiviteter och jobb kan sedan ange en condition baserat på den statusen för att avgöra om den ska köras.

Villkorsegenskapen anger under vilka villkor aktiviteten körs. Som standard körs ett steg om inget i jobbet misslyckades ännu och steget omedelbart före det slutfördes.

Du kan åsidosätta eller anpassa dessa standardvärden genom att ange att steget ska köras även om eller bara om ett tidigare beroende misslyckas eller har ett annat resultat. Du kan också definiera anpassade villkor som består av uttryck.

Villkor som baseras på tidigare beroendestatus är:

• Lyckades: Kör endast om alla tidigare beroenden lyckas. Det här beteendet är standard om inget villkor anges i YAML. Om du vill tillämpa det här villkoret anger du condition: succeeded().
• Lyckades eller misslyckades: Kör även om ett tidigare beroende misslyckas, såvida inte körningen avbryts. Om du vill tillämpa det här villkoret anger du condition: succeededOrFailed().
• Alltid: Kör även om ett tidigare beroende misslyckas, även om körningen avbryts. Om du vill tillämpa det här villkoret anger du condition: always().
• Misslyckades: Kör endast när ett tidigare beroende misslyckas. Om du vill tillämpa det här villkoret anger du condition: failed().

I följande YAML-exempel PublishTestResults@2 körs även om föregående steg misslyckades på grund av dess succeededOrFailed-villkor .

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.x'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Fortsätt vid fel

Egenskapen continueOnError anger om aktiviteten ska fortsätta köras och rapportera lyckade resultat oavsett fel. Om värdet är anger trueden här egenskapen att aktiviteten ska ignorera en failed status och fortsätta att köras. Underordnade steg och jobb behandlar aktivitetsresultatet som success när de fattar sina körningsbeslut.

Aktiverat

Som standard körs aktiviteten när jobbet körs. Du kan ange enabled att false aktiviteten ska inaktiveras. Att tillfälligt inaktivera uppgiften är användbart för att ta bort uppgiften från processen i testsyfte eller för specifika distributioner.

Antal återförsök vid aktivitetsfel

Egenskapen retryCountOnTaskFailure anger hur många gånger aktiviteten ska försöka igen om den misslyckas. Standardvärdet är noll återförsök.

• Det maximala antalet återförsök som tillåts är 10.
• Väntetiden innan återförsöket ökar efter varje misslyckat försök, efter en exponentiell backoff-strategi. Det första återförsöket sker efter 1 sekund, det andra återförsöket efter 4 sekunder och det tionde återförsöket efter 100 sekunder.
• Att försöka utföra uppgiften igen ger inte idempotens. Biverkningar av det första försöket, till exempel att delvis skapa en extern resurs, kan leda till att återförsök misslyckas.
• Ingen information om antalet återförsök görs tillgänglig för aktiviteten.
• Aktivitetsfel lägger till en varning i aktivitetsloggarna som anger att den misslyckades innan aktiviteten försöker igen.
• Alla återförsök visas i användargränssnittet som en del av samma aktivitetsnod.

resources:
  containers:
  - container: pycontainer
    image: python:3.11

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Timeout

Tidsgränsen börjar när aktiviteten börjar köras och inkluderar inte den tid då aktiviteten placeras i kö eller väntar på en agent.

I klassiska pipelines erbjuder aktiviteter flera kontrollalternativ.

Aktiverat

Avmarkera kryssrutan Aktiverad för att inaktivera en uppgift. Att tillfälligt inaktivera uppgiften är användbart för att ta bort uppgiften från processen i testsyfte eller för specifika distributioner.

Fortsätt vid fel

Välj det här alternativet om du vill att aktiviteten ska rapportera lyckad aktivitet även om den misslyckas, vilket möjligen tillåter att beroende uppgifter i samma jobb körs. Den övergripande versionen eller distributionen får inte vara mer än delvis lyckad. Om efterföljande aktiviteter körs beror också på deras kör den här aktivitetsinställningen .

Antal återförsök om uppgiften misslyckades

Ange antalet återförsök om den här aktiviteten misslyckas. Standardvärdet är noll.

• Den misslyckade uppgiften försöker igen efter några sekunder. Väntetiden innan återförsöket ökar efter varje misslyckat försök.
• Att försöka utföra uppgiften igen ger inte idempotens. Biverkningar av det första försöket, till exempel att delvis skapa en extern resurs, kan leda till att återförsök misslyckas.
• Ingen information om antalet återförsök görs tillgänglig för aktiviteten.
• Aktivitetsfel lägger till en varning i aktivitetsloggarna som anger att den misslyckades innan aktiviteten försöker igen.
• Alla återförsök visas i användargränssnittet som en del av samma aktivitetsnod.

Timeout

Ange den maximala tiden i minuter som aktiviteten kan köras innan den avbryts automatiskt. Standardvärdet är 0, eller oändlig tid. Om du anger ett annat värde än noll åsidosätts inställningen för det överordnade aktivitetsjobbet. Tidsgränsen börjar när aktiviteten börjar köras och inkluderar inte den tid då aktiviteten placeras i kö eller väntar på en agent.

Kör den här uppgiften

Välj något av följande villkor för att köra den här uppgiften:

• Endast när alla tidigare uppgifter har slutförts. Det här villkoret är standard.
• Även om en tidigare aktivitet har misslyckats, såvida inte bygget avbröts
• Även om en tidigare aktivitet har misslyckats, även om bygget avbröts
• Endast när en tidigare aktivitet har misslyckats
• Anpassade villkor och ange sedan ett anpassat villkor som anger ett uttryck för när den här aktiviteten ska köras.

En YAML-pipelineaktivitet kan ange en env egenskap som visar namn-/värdesträngar som representerar miljövariabler.

- task: AzureCLI@2
  env:
    ENV_VARIABLE_NAME: value
    ENV_VARIABLE_NAME2: value
  ...

Du kan ange miljövariabler med hjälp script av steg eller med hjälp av skript i kommandorads-, Bash- eller PowerShell-uppgifter.

I följande exempel körs ett script steg som tilldelar ett värde till ENV_VARIABLE_NAME miljövariabeln och ekar värdet.

- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

Föregående skript fungerar på samma sätt som när du kör en Bash@3 uppgift med indata script . I följande exempel används syntaxen task .

- task: Bash@3
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: value
  displayName: 'echo environment variable'

I klassiska pipelines kan du lägga till och redigera miljövariabler i avsnittet Miljövariabler i aktivitetsredigeraren .

Skapa en azure-pipelines.yml fil med följande innehåll i projektets baskatalog.

pool:
  vmImage: 'windows-latest'

jobs:
- job: NodeJS
  strategy:
    matrix:
      node14:
        nodeVersion: '14.x'
      node16:
        nodeVersion: '16.x'
    maxParallel: 2
  steps:
    - task: NodeTool@0
      displayName: 'Install Node.js $(nodeVersion)'
      inputs:
        versionSpec: '$(nodeVersion)'
        checkLatest: true

    - script: |
        echo Using Node version $(nodeVersion)
        node --version
      displayName: 'Verify Node Installation'

Spara och kör pipelinen. Jobbet körs två gånger, en för varje version av Node.js som du angav i variabeln nodeVersion .

Installationsprogrammet för Node.js-verktyget laddar ned den Node.js versionen om den inte redan finns på agenten. Kommandoradsskriptet skriver den installerade versionen till kommandoraden.

1. I agentjobbet för den klassiska pipelinen, under Körningsplan, anger du Parallellitet till Multi-configuration.

2. Under Multiplikatorer anger du nodeVersion.

3. Ange Maximalt antal agenter till 2.

4. Lägg till installationsuppgiften förNode.js-verktyget i pipelinen med följande inställningar:

   • Ange $(nodeVersion) under Versionsspecifikation.
   • Markera kryssrutan för Sök efter senaste version.

5. Lägg till kommandoradsaktiviteten i pipelinen och ange följande kod under Skript:

   echo Using Node version $(nodeVersion)
node --version

6. På fliken Variabler definierar du variabelnodversion med värdet 14.x, 16.x och väljer Settable vid kötid.

   Anteckning

   I en versionspipeline väljer du Settable vid lanseringstillfället. Mer information finns i Hur kan jag redigera variabler vid lansering?

7. Välj Spara och kö.

8. På skärmen Kör pipeline väljer du Spara och kör.

Jobbet körs två gånger, en för varje version av Node.js som du angav i variabeln nodeVersion . Installationsuppgiften förNode.js-verktyget laddar ned Node.js versionen om den inte redan finns på agenten. Kommandoradsaktiviteten loggar platsen för den Node.js versionen på disken.