Voorwaarden opgeven

  • Artikel

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

U kunt de voorwaarden opgeven waaronder elke fase, taak of stap wordt uitgevoerd. Een taak of fase wordt standaard uitgevoerd als deze niet afhankelijk is van een andere taak of fase, of als alle taken of fasen ervan afhankelijk zijn van voltooid en voltooid. Dit omvat niet alleen directe afhankelijkheden, maar ook hun afhankelijkheden, die recursief worden berekend. Standaard wordt een stap uitgevoerd als er nog niets in de taak is mislukt en de stap die direct aan de taak voorafgaat, is voltooid. U kunt dit gedrag aanpassen door een fase, taak of stap af te dwingen om te worden uitgevoerd, ook als een eerdere afhankelijkheid mislukt of door een aangepaste voorwaarde op te geven.

U kunt voorwaarden opgeven waaronder een stap, taak of fase wordt uitgevoerd.

  • Alleen wanneer alle vorige directe en indirecte afhankelijkheden met dezelfde agentgroep zijn geslaagd. Als u verschillende agentpools hebt, worden deze fasen of taken gelijktijdig uitgevoerd. Dit is de standaardinstelling als er geen voorwaarde is ingesteld in de YAML.

  • Zelfs als een eerdere afhankelijkheid is mislukt, tenzij de uitvoering is geannuleerd. Gebruik succeededOrFailed() in de YAML voor deze voorwaarde.

  • Zelfs als een eerdere afhankelijkheid is mislukt, zelfs als de uitvoering is geannuleerd. Gebruik always() in de YAML voor deze voorwaarde.

  • Alleen wanneer een eerdere afhankelijkheid is mislukt. Gebruik failed() in de YAML voor deze voorwaarde.

  • Aangepaste voorwaarden

Standaard worden stappen, taken en fasen uitgevoerd als alle directe en indirecte afhankelijkheden zijn geslaagd. Het is alsof u 'voorwaarde: succeeded()' hebt opgegeven (zie de statusfunctie geslaagd).

jobs:
- job: Foo

  steps:
  - script: echo Hello!
    condition: always() # this step will always run, even if the pipeline is canceled

- job: Bar
  dependsOn: Foo
  condition: failed() # this job will only run if Foo fails

U kunt ook variabelen in voorwaarden gebruiken.

variables:
  isMain: $[eq(variables['Build.SourceBranch'], 'refs/heads/main')]

stages:
- stage: A
  jobs:
  - job: A1
    steps:
      - script: echo Hello Stage A!

- stage: B
  condition: and(succeeded(), eq(variables.isMain, true))
  jobs:
  - job: B1
    steps:
      - script: echo Hello Stage B!
      - script: echo $(isMain)

Voorwaarden worden geëvalueerd om te bepalen of een fase, taak of stap moet worden gestart. Dit betekent dat er niets dat tijdens runtime in die werkeenheid wordt berekend, beschikbaar is. Als u bijvoorbeeld een taak hebt waarmee een variabele wordt ingesteld met behulp van een runtime-expressie met behulp van $[ ] syntaxis, kunt u die variabele niet gebruiken in uw aangepaste voorwaarde.

YAML wordt niet ondersteund in TFS.

Notitie

Wanneer u uw eigen condition eigenschap opgeeft voor een fase/taak/stap, overschrijft u de standaardwaarde condition: succeeded(). Dit kan leiden tot de fase/taak/stap die wordt uitgevoerd, zelfs als de build is geannuleerd. Zorg ervoor dat u rekening houdt met de status van de bovenliggende fase/taak bij het schrijven van uw eigen voorwaarden.

Een aangepaste voorwaarde inschakelen

Als de ingebouwde voorwaarden niet aan uw behoeften voldoen, kunt u aangepaste voorwaarden opgeven.

Voorwaarden worden in YAML-pijplijnen als expressies geschreven. De agent evalueert de expressie, te beginnen met de binnenste functie, en werkt naar buiten toe. Het uiteindelijke resultaat is een booleaanse waarde die bepaalt of de taak of fase moet worden uitgevoerd of niet. Zie het artikel over expressies voor een volledige handleiding voor de syntaxis.

Kan op basis van een van de voorwaarden de taak worden uitgevoerd, ook nadat de build door een gebruiker is geannuleerd? Zo ja, geef dan een redelijke waarde op voor time-outs voor annuleren, zodat dit soort taken voldoende tijd hebben om te voltooien nadat de gebruiker een uitvoering heeft geannuleerd.

Gedrag van pijplijn wanneer de build wordt geannuleerd

Wanneer een build wordt geannuleerd, betekent dit niet dat alle fasen, taken of stappen niet meer worden uitgevoerd. De beslissing is afhankelijk van de fase, taak of stap conditions die u hebt opgegeven en op welk moment van de uitvoering van de pijplijn u de build hebt geannuleerd.

Als uw voorwaarde niet rekening houdt met de status van het bovenliggende element van uw fase/taak/stap, wordt uw fase, taak of stap uitgevoerd als de voorwaarde truewordt geëvalueerd, zelfs als het bovenliggende item wordt geannuleerd. Als het bovenliggende item wordt overgeslagen, wordt uw fase, taak of stap niet uitgevoerd.

We bekijken enkele voorbeelden.

In deze pijplijn is standaard stage2 afhankelijk van en stage2 is er een condition set stage1 ingesteld. stage2 wordt alleen uitgevoerd wanneer de bronbranch zich bevindt main.

stages:
- stage: stage1
  jobs:
  - job: A
    steps:
      - script: echo 1; sleep 30
- stage: stage2
  condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
  jobs:
  - job: B
    steps:
      - script: echo 2

Als u een build in de wachtrij plaatst op de main vertakking en u deze annuleert terwijl stage1 deze wordt uitgevoerd, stage2 wordt deze nog steeds uitgevoerd, omdat eq(variables['Build.SourceBranch'], 'refs/heads/main') dit truewordt geëvalueerd.

In deze pijplijn is stage2 dit afhankelijk stage1van. Job B heeft er een condition set voor.

stages:
- stage: stage1
  jobs:
  - job: A
    steps:
      - script: echo 1; sleep 30
- stage: stage2
  jobs:
  - job: B
    condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')
    steps:
      - script: echo 2

Als u een build in de wachtrij op de main vertakking zet en u deze annuleert terwijl stage1 deze wordt uitgevoerd, stage2wordt deze niet uitgevoerd, ook al bevat het een taak B waarvan de voorwaarde wordt geëvalueerd true. De reden hiervoor is dat stage2 de standaardwaarde condition: succeeded()is, die evalueert false wanneer stage1 wordt geannuleerd. Daarom wordt stage2 overgeslagen en worden de taken niet uitgevoerd.

Stel dat u de volgende YAML-pijplijn hebt. U ziet dat stage2 standaard afhankelijk is van stage1 en dat script: echo 2 er een condition set voor is ingesteld.

stages:
- stage: stage1
  jobs:
  - job: A
    steps:
      - script: echo 1; sleep 30
- stage: stage2
  jobs:
  - job: B
    steps:
      - script: echo 2
        condition: eq(variables['Build.SourceBranch'], 'refs/heads/main')

Als u een build in de wachtrij op de main vertakking zet en u deze annuleert terwijl stage1 deze wordt uitgevoerd,stage2 wordt deze niet uitgevoerd, ook al bevat het een stap in de taak B waarvan de voorwaarde wordt geëvalueerdtrue. De reden hiervoor is dat stage2 het wordt overgeslagen als reactie op stage1 annuleren.

Als u wilt voorkomen dat fasen, taken of stappen worden conditions uitgevoerd wanneer een build wordt geannuleerd, moet u rekening houden met de status van de bovenliggende gebruiker bij het schrijven van de conditions. Zie Taakstatusfuncties voor meer informatie.

Voorbeelden

Uitvoeren voor de hoofdbranch, zelfs als deze is geannuleerd, zelfs als dit mislukt

eq(variables['Build.SourceBranch'], 'refs/heads/main')

Uitvoeren voor de hoofdvertakking, indien geslaagd

and(succeeded(), eq(variables['Build.SourceBranch'], 'refs/heads/main'))

Uitvoeren als de vertakking niet de hoofdvertakking is, als het slaagt

and(succeeded(), ne(variables['Build.SourceBranch'], 'refs/heads/main'))

Uitvoeren voor vertakkingen van gebruikersonderwerp, indien geslaagd

and(succeeded(), startsWith(variables['Build.SourceBranch'], 'refs/heads/users/'))

Uitvoeren voor CI-builds (continue integratie) als dit lukt

and(succeeded(), in(variables['Build.Reason'], 'IndividualCI', 'BatchedCI'))

Uitvoeren als de build wordt uitgevoerd door een vertakkingsbeleid voor een pull-aanvraag, als dit mislukt

and(failed(), eq(variables['Build.Reason'], 'PullRequest'))

Uitvoeren als de build is gepland, zelfs als deze mislukt, zelfs als deze is geannuleerd

eq(variables['Build.Reason'], 'Schedule')

Release.Artifacts. {artifact-alias}. SourceBranch is gelijk aan Build.SourceBranch.

Altijd uitvoeren als een variabele is ingesteld op true, zelfs als deze is geannuleerd, zelfs als deze mislukt

eq(variables['System.debug'], true)

Uitvoeren als een variabele null is (lege tekenreeks)

Omdat alle variabelen worden behandeld als tekenreeksen in Azure Pipelines, is een lege tekenreeks gelijk aan null in deze pijplijn.

variables:
- name: testEmpty
  value: ''

jobs:
  - job: A
    steps:
    - script: echo testEmpty is blank
    condition: eq(variables.testEmpty, '')

Een sjabloonparameter gebruiken als onderdeel van een voorwaarde

Wanneer u een parameter declareert in dezelfde pijplijn waarin een voorwaarde voorkomt, vindt parameteruitbreiding plaats voordat er op voorwaarden wordt gelet. In dit geval kunt u parameters insluiten binnen voorwaarden. Het script in dit YAML-bestand wordt uitgevoerd omdat parameters.doThing dit waar is.

De condition in de pijplijn combineert twee functies: succeeded() en eq('${{ parameters.doThing }}', true). De succeeded() functie controleert of de vorige stap is geslaagd. De succeeded() functie retourneert waar omdat er geen vorige stap is.

De eq('${{ parameters.doThing }}', true) functie controleert of de doThing-parameter gelijk is aan true. Omdat de standaardwaarde voor doThing waar is, retourneert de voorwaarde standaard true, tenzij een andere waarde wordt ingesteld in de pijplijn.

Zie Sjabloontypen en -gebruik voor meer voorbeelden van sjabloonparameters.

parameters:
- name: doThing
  default: true
  type: boolean

steps:
- script: echo I did a thing
  condition: ${{ eq(parameters.doThing, true) }}

Wanneer u een parameter doorgeeft aan een sjabloon, moet u de waarde van de parameter instellen in uw sjabloon of templateContext gebruiken om eigenschappen door te geven aan sjablonen.

# parameters.yml
parameters:
- name: doThing
  default: true # value passed to the condition
  type: boolean

jobs:
  - job: B
    steps:
    - script: echo I did a thing
    condition: ${{ eq(parameters.doThing, true) }}

# azure-pipeline.yml
parameters:
- name: doThing
  default: true 
  type: boolean

trigger:
- none

extends:
  template: parameters.yml

De uitvoer van deze pijplijn komt I did a thing omdat de parameter doThing waar is.

De uitvoervariabele van een taak gebruiken in een voorwaarde in een volgende taak

U kunt een variabele beschikbaar maken voor toekomstige taken en deze opgeven in een voorwaarde. Variabelen die beschikbaar zijn voor toekomstige taken, moeten worden gemarkeerd als uitvoervariabelen voor meerdere taken met behulp van isOutput=true.

jobs:
- job: Foo
  steps:
  - bash: |
      echo "This is job Foo."
      echo "##vso[task.setvariable variable=doThing;isOutput=true]Yes" #set variable doThing to Yes
    name: DetermineResult
- job: Bar
  dependsOn: Foo
  condition: eq(dependencies.Foo.outputs['DetermineResult.doThing'], 'Yes') #map doThing and check the value
  steps:
  - script: echo "Job Foo ran and doThing is Yes."

De pijplijnvariabele gebruiken die is gemaakt op basis van een stap in een voorwaarde in een volgende stap

U kunt een variabele beschikbaar maken voor toekomstige stappen en deze opgeven in een voorwaarde. Variabelen die zijn gemaakt op basis van een stap, zijn standaard beschikbaar voor toekomstige stappen en hoeven niet te worden gemarkeerd als uitvoervariabelen voor meerdere taken met behulp van isOutput=true.

Er zijn enkele belangrijke dingen die u moet weten met betrekking tot de bovenstaande benadering en het bereik:

  • Variabelen die zijn gemaakt in een stap in een taak, worden afgestemd op de stappen in dezelfde taak.
  • Variabelen die in een stap zijn gemaakt, zijn alleen beschikbaar in de volgende stappen als omgevingsvariabelen.
  • Variabelen die in een stap zijn gemaakt, kunnen niet worden gebruikt in de stap die deze definieert.

Hieronder ziet u een voorbeeld van het maken van een pijplijnvariabele in een stap en het gebruik van de variabele in de voorwaarde en het script van een volgende stap.

steps:

# This step creates a new pipeline variable: doThing. This variable will be available to subsquent steps.
- bash: |
    echo "##vso[task.setvariable variable=doThing]Yes"
  displayName: Step 1

# This step is able to use doThing, so it uses it in its condition
- script: |
    # You can access the variable from Step 1 as an environment variable.
    echo "Value of doThing (as DOTHING env var): $DOTHING."
  displayName: Step 2
  condition: and(succeeded(), eq(variables['doThing'], 'Yes')) # or and(succeeded(), eq(variables.doThing, 'Yes'))

Veelgestelde vragen

Hoe kan ik een taak activeren als een vorige taak problemen heeft gegeven?

U kunt het resultaat van de vorige taak gebruiken. In dit YAML-bestand kan de taak eq(dependencies.A.result,'SucceededWithIssues') bijvoorbeeld worden uitgevoerd omdat taak A is geslaagd met problemen.

jobs:
- job: A
  displayName: Job A
  continueOnError: true # next job starts even if this one fails
  steps:
  - script: echo Job A ran
  - script: exit 1

- job: B
  dependsOn: A
  condition: eq(dependencies.A.result,'SucceededWithIssues') # targets the result of the previous job 
  displayName: Job B
  steps:
  - script: echo Job B ran

Ik heb mijn build geannuleerd, maar het wordt nog steeds uitgevoerd. Wat is er gaande?

U ondervindt dit probleem als de voorwaarde die is geconfigureerd in de fase geen functie voor taakstatuscontrole bevat. U kunt het probleem oplossen door een functie voor taakstatuscontrole toe te voegen aan de voorwaarde. Als u een taak annuleert terwijl deze in de wachtrij staat, maar niet wordt uitgevoerd, wordt de hele taak geannuleerd, inclusief alle andere fasen.

Meer informatie over het gedrag van een pijplijn wanneer een build wordt geannuleerd.