Delen via


Taken opgeven in uw pijplijn

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

U kunt uw pijplijn ordenen in taken. Elke pijplijn heeft ten minste één taak. Een taak is een reeks stappen die opeenvolgend als een eenheid worden uitgevoerd. Met andere woorden, een taak is de kleinste werkeenheid die kan worden gepland om te worden uitgevoerd.

Zie Belangrijke concepten voor nieuwe Azure Pipelines-gebruikers voor meer informatie over de belangrijkste concepten en onderdelen waaruit een pijplijn bestaat.

Azure Pipelines biedt geen ondersteuning voor taakprioriteit voor YAML-pijplijnen. Als u wilt bepalen wanneer taken worden uitgevoerd, kunt u voorwaarden en afhankelijkheden opgeven.

Eén taak definiëren

In het eenvoudigste geval heeft een pijplijn één taak. In dat geval hoeft u het job trefwoord alleen expliciet te gebruiken als u een sjabloon gebruikt. U kunt de stappen in uw YAML-bestand rechtstreeks opgeven.

Dit YAML-bestand heeft een taak die wordt uitgevoerd op een door Microsoft gehoste agent en uitvoer Hello world.

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

U kunt meer eigenschappen voor die taak opgeven. In dat geval kunt u het job trefwoord gebruiken.

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Uw pijplijn kan meerdere taken hebben. Gebruik in dat geval het jobs trefwoord.

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Uw pijplijn kan meerdere fasen hebben, elk met meerdere taken. Gebruik in dat geval het stages trefwoord.

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

De volledige syntaxis voor het opgeven van een taak is:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container

De volledige syntaxis voor het opgeven van een taak is:

- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  displayName: string  # friendly name to display in the UI
  dependsOn: string | [ string ]
  condition: string
  strategy:
    parallel: # parallel strategy
    matrix: # matrix strategy
    maxParallel: number # maximum number simultaneous matrix legs to run
    # note: `parallel` and `matrix` are mutually exclusive
    # you may specify one or the other; including both is an error
    # `maxParallel` is only valid with `matrix`
  continueOnError: boolean  # 'true' if future jobs should run even if this job fails; defaults to 'false'
  pool: pool # agent pool
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs
  container: containerReference # container to run this job inside
  timeoutInMinutes: number # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: number # how much time to give 'run always even if cancelled tasks' before killing them
  variables: { string: string } | [ variable | variableReference ] 
  steps: [ script | bash | pwsh | powershell | checkout | task | templateReference ]
  services: { string: string | container } # container resources to run as a service container
  uses: # Any resources (repos or pools) required by this job that are not already referenced
    repositories: [ string ] # Repository references to Azure Git repositories
    pools: [ string ] # Pool names, typically when using a matrix strategy for the job

Als de primaire bedoeling van uw taak is om uw app te implementeren (in tegenstelling tot het bouwen of testen van uw app), kunt u een speciaal type taak gebruiken met de naam implementatietaak.

De syntaxis voor een implementatietaak is:

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Hoewel u stappen voor implementatietaken in een jobkunt toevoegen, wordt u aangeraden in plaats daarvan een implementatietaak te gebruiken. Een implementatietaak heeft enkele voordelen. U kunt bijvoorbeeld implementeren in een omgeving, waaronder voordelen zoals het bekijken van de geschiedenis van wat u hebt geïmplementeerd.

Typen taken

Taken kunnen van verschillende typen zijn, afhankelijk van waar ze worden uitgevoerd.

  • Agentpooltaken worden uitgevoerd op een agent in een agentpool.
  • Servertaken worden uitgevoerd op de Azure DevOps Server.

Agentpooltaken

Dit zijn het meest voorkomende type taken en ze worden uitgevoerd op een agent in een agentgroep.

  • Wanneer u door Microsoft gehoste agents gebruikt, krijgt elke taak in een pijplijn een nieuwe agent.
  • Gebruik vereisten met zelf-hostende agents om op te geven welke mogelijkheden een agent moet hebben om uw taak uit te voeren. Mogelijk krijgt u dezelfde agent voor opeenvolgende taken, afhankelijk van of er meer dan één agent in uw agentpool is die overeenkomt met de vereisten van uw pijplijn. Als er slechts één agent in uw pool is die voldoet aan de vereisten van de pijplijn, wacht de pijplijn tot deze agent beschikbaar is.

Notitie

Eisen en mogelijkheden zijn ontworpen voor gebruik met zelf-hostende agents, zodat taken kunnen worden gekoppeld aan een agent die voldoet aan de vereisten van de taak. Wanneer u door Microsoft gehoste agents gebruikt, selecteert u een installatiekopie voor de agent die voldoet aan de vereisten van de taak, dus hoewel het mogelijk is om mogelijkheden toe te voegen aan een door Microsoft gehoste agent, hoeft u geen mogelijkheden te gebruiken met door Microsoft gehoste agents.

pool:
  name: myPrivateAgents    # your job runs on an agent in this pool
  demands: agent.os -equals Windows_NT    # the agent must have this capability to run the job
steps:
- script: echo hello world

Of meerdere vereisten:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Meer informatie over agentmogelijkheden.

Servertaken

Taken in een servertaak worden ingedeeld en uitgevoerd op de server (Azure Pipelines of TFS). Voor een servertaak is geen agent of doelcomputers vereist. Er worden nu slechts enkele taken ondersteund in een servertaak. De maximale tijd voor een servertaak is 30 dagen.

Ondersteunde taken zonder agent

Op dit moment worden alleen de volgende taken ondersteund voor taken zonder agent:

Omdat taken uitbreidbaar zijn, kunt u meer zonder agent taken toevoegen met behulp van extensies. De standaardtime-out voor taken zonder agent is 60 minuten.

De volledige syntaxis voor het opgeven van een servertaak is:

jobs:
- job: string
  timeoutInMinutes: number
  cancelTimeoutInMinutes: number
  strategy:
    maxParallel: number
    matrix: { string: { string: string } }

  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

U kunt ook de vereenvoudigde syntaxis gebruiken:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Afhankelijkheden

Wanneer u meerdere taken in één fase definieert, kunt u er afhankelijkheden tussen opgeven. Pijplijnen moeten ten minste één taak bevatten zonder afhankelijkheden. Azure DevOps YAML-pijplijntaken worden standaard parallel uitgevoerd, tenzij de dependsOn waarde is ingesteld.

Notitie

Elke agent kan slechts één taak tegelijk uitvoeren. Als u meerdere taken parallel wilt uitvoeren, moet u meerdere agents configureren. U hebt ook voldoende parallelle taken nodig.

De syntaxis voor het definiëren van meerdere taken en de bijbehorende afhankelijkheden is:

jobs:
- job: string
  dependsOn: string
  condition: string

Voorbeeldtaken die opeenvolgend worden gebouwd:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Voorbeeldtaken die parallel worden gebouwd (geen afhankelijkheden):

jobs:
- job: Windows
  pool:
    vmImage: 'windows-latest'
  steps:
  - script: echo hello from Windows
- job: macOS
  pool:
    vmImage: 'macOS-latest'
  steps:
  - script: echo hello from macOS
- job: Linux
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: echo hello from Linux

Voorbeeld van uitwaaier:

jobs:
- job: InitialJob
  steps:
  - script: echo hello from initial job
- job: SubsequentA
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent A
- job: SubsequentB
  dependsOn: InitialJob
  steps:
  - script: echo hello from subsequent B

Voorbeeld van fan-in:

jobs:
- job: InitialA
  steps:
  - script: echo hello from initial A
- job: InitialB
  steps:
  - script: echo hello from initial B
- job: Subsequent
  dependsOn:
  - InitialA
  - InitialB
  steps:
  - script: echo hello from subsequent

Voorwaarden

U kunt de voorwaarden opgeven waaronder elke taak wordt uitgevoerd. Een taak wordt standaard uitgevoerd als deze niet afhankelijk is van een andere taak of als alle taken waarvan deze afhankelijk is, zijn voltooid en geslaagd. U kunt dit gedrag aanpassen door af te dwingen dat een taak wordt uitgevoerd, zelfs als een vorige taak mislukt of door een aangepaste voorwaarde op te geven.

Voorbeeld van het uitvoeren van een taak op basis van de status van het uitvoeren van een vorige taak:

jobs:
- job: A
  steps:
  - script: exit 1

- job: B
  dependsOn: A
  condition: failed()
  steps:
  - script: echo this will run when A fails

- job: C
  dependsOn:
  - A
  - B
  condition: succeeded('B')
  steps:
  - script: echo this will run when B runs and succeeds

Voorbeeld van het gebruik van een aangepaste voorwaarde:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

U kunt opgeven dat een taak wordt uitgevoerd op basis van de waarde van een uitvoervariabele die is ingesteld in een vorige taak. In dit geval kunt u alleen variabelen gebruiken die zijn ingesteld in rechtstreeks afhankelijke taken:

jobs:
- job: A
  steps:
  - script: "echo '##vso[task.setvariable variable=skipsubsequent;isOutput=true]false'"
    name: printvar

- job: B
  condition: and(succeeded(), ne(dependencies.A.outputs['printvar.skipsubsequent'], 'true'))
  dependsOn: A
  steps:
  - script: echo hello from B

Time-outs

Om te voorkomen dat resources worden gebruikt wanneer uw taak niet reageert of te lang wacht, is het een goed idee om een limiet in te stellen voor hoe lang uw taak mag worden uitgevoerd. Gebruik de time-outinstelling voor de taak om de limiet in minuten aan te geven voor het uitvoeren van de taak. Als u de waarde instelt op nul , betekent dit dat de taak kan worden uitgevoerd:

  • Voor altijd op zelf-hostende agents
  • Gedurende 360 minuten (6 uur) op door Microsoft gehoste agents met een openbaar project en een openbare opslagplaats
  • Gedurende 60 minuten op door Microsoft gehoste agents met een privéproject of privéopslagplaats (tenzij extra capaciteit wordt betaald)

De time-outperiode begint wanneer de taak wordt uitgevoerd. Het omvat niet de tijd waarop de taak in de wachtrij staat of wacht op een agent.

Hiermee timeoutInMinutes kan een limiet worden ingesteld voor de uitvoeringstijd van de taak. Wanneer dit niet is opgegeven, is de standaardwaarde 60 minuten. Wanneer 0 dit is opgegeven, wordt de maximumlimiet gebruikt (hierboven beschreven).

Hiermee cancelTimeoutInMinutes kan een limiet worden ingesteld voor de tijd voor het annuleren van de taak wanneer de implementatietaak is ingesteld om actief te blijven als een vorige taak is mislukt. Wanneer dit niet is opgegeven, is de standaardwaarde vijf minuten. De waarde moet tussen 1 en 35790 minuten liggen.

jobs:
- job: Test
  timeoutInMinutes: 10 # how long to run the job before automatically cancelling
  cancelTimeoutInMinutes: 2 # how much time to give 'run always even if cancelled tasks' before stopping them

Time-outs hebben het volgende prioriteitsniveau.

  1. Op door Microsoft gehoste agents zijn taken beperkt in hoe lang ze kunnen worden uitgevoerd op basis van het projecttype en of ze worden uitgevoerd met behulp van een betaalde parallelle taak. Wanneer het time-outinterval van de door Microsoft gehoste taak is verstreken, wordt de taak beëindigd. Op door Microsoft gehoste agents kunnen taken niet langer worden uitgevoerd dan dit interval, ongeacht time-outs op taakniveau die zijn opgegeven in de taak.
  2. De time-out die op taakniveau is geconfigureerd, geeft de maximale duur aan voor de taak die moet worden uitgevoerd. Wanneer het time-outinterval op taakniveau is verstreken, wordt de taak beëindigd. Als de taak wordt uitgevoerd op een door Microsoft gehoste agent, heeft het instellen van de time-out op taakniveau een interval dat groter is dan de ingebouwde time-out op het niveau van de door Microsoft gehoste taak geen effect en wordt de time-out van de door Microsoft gehoste taak gebruikt.
  3. U kunt ook de time-out voor elke taak afzonderlijk instellen. Zie opties voor taakbeheer. Als het time-outinterval op taakniveau is verstreken voordat de taak is voltooid, wordt de actieve taak beëindigd, zelfs als de taak is geconfigureerd met een langer time-outinterval.

Configuratie met meerdere taken

Vanuit één taak die u ontwerpt, kunt u meerdere taken parallel uitvoeren op meerdere agents. Enkele voorbeelden:

  • Builds met meerdere configuraties: u kunt meerdere configuraties parallel bouwen. U kunt bijvoorbeeld een Visual C++-app bouwen voor zowel debug als release configuraties op beide x86 platforms.x64 Zie Visual Studio Build : meerdere configuraties voor meerdere platforms voor meer informatie.

  • Implementaties met meerdere configuraties: u kunt meerdere implementaties parallel uitvoeren, bijvoorbeeld naar verschillende geografische regio's.

  • Testen met meerdere configuraties: u kunt meerdere configuraties parallel testen.

  • Met meerdere configuraties wordt altijd ten minste één taak gegenereerd, zelfs als een variabele voor meerdere configuraties leeg is.

Met de matrix strategie kan een taak meerdere keren worden verzonden, met verschillende variabelensets. De maxParallel tag beperkt de hoeveelheid parallelle uitvoering. De volgende taak wordt drie keer verzonden met de waarden van Locatie en Browser ingesteld zoals opgegeven. Er worden echter slechts twee taken tegelijk uitgevoerd.

jobs:
- job: Test
  strategy:
    maxParallel: 2
    matrix: 
      US_IE:
        Location: US
        Browser: IE
      US_Chrome:
        Location: US
        Browser: Chrome
      Europe_Chrome:
        Location: Europe
        Browser: Chrome

Notitie

Matrixconfiguratienamen (zoals US_IE hierboven) mogen alleen eenvoudige Latijnse alfabetletters (A-Z, a-z), cijfers en onderstrepingstekens (_) bevatten. Ze moeten beginnen met een letter. Ze moeten ook 100 tekens of minder zijn.

Het is ook mogelijk om uitvoervariabelen te gebruiken om een matrix te genereren. Dit kan handig zijn als u de matrix wilt genereren met behulp van een script.

matrix accepteert een runtime-expressie die een tekenreeks-JSON-object bevat. Dat JSON-object, wanneer dit wordt uitgevouwen, moet overeenkomen met de syntaxis van de matrix. In het onderstaande voorbeeld hebben we de JSON-tekenreeks in code vastgelegd, maar deze kan worden gegenereerd door een scripttaal of opdrachtregelprogramma.

jobs:
- job: generator
  steps:
  - bash: echo "##vso[task.setVariable variable=legs;isOutput=true]{'a':{'myvar':'A'}, 'b':{'myvar':'B'}}"
    name: mtrx
  # This expands to the matrix
  #   a:
  #     myvar: A
  #   b:
  #     myvar: B
- job: runner
  dependsOn: generator
  strategy:
    matrix: $[ dependencies.generator.outputs['mtrx.legs'] ]
  steps:
  - script: echo $(myvar) # echos A or B depending on which leg is running

Snijden

Een agenttaak kan worden gebruikt om een reeks tests parallel uit te voeren. U kunt bijvoorbeeld een grote suite van 1000 tests uitvoeren op één agent. U kunt ook twee agents gebruiken en 500 tests tegelijk uitvoeren.

Als u segmentering wilt toepassen, moeten de taken in de taak slim genoeg zijn om inzicht te hebben in het segment waartoe ze behoren.

De Visual Studio Test-taak is een dergelijke taak die ondersteuning biedt voor testlicing. Als u meerdere agents hebt geïnstalleerd, kunt u opgeven hoe de Visual Studio Test-taak parallel op deze agents wordt uitgevoerd.

Met de parallel strategie kan een taak vaak worden gedupliceerd. Variabelen System.JobPositionInPhase en System.TotalJobsInPhase worden aan elke taak toegevoegd. De variabelen kunnen vervolgens in uw scripts worden gebruikt om werk over de taken te verdelen. Zie Parallelle en meerdere uitvoeringen met behulp van agenttaken.

De volgende taak wordt vijf keer verzonden met de waarden van System.JobPositionInPhase en System.TotalJobsInPhase op de juiste manier ingesteld.

jobs:
- job: Test
  strategy:
    parallel: 5

Taakvariabelen

Als u YAML gebruikt, kunnen variabelen worden opgegeven voor de taak. De variabelen kunnen worden doorgegeven aan taakinvoer met behulp van de macrosyntaxis $(variableName) of worden geopend in een script met behulp van de fasevariabele.

Hier volgt een voorbeeld van het definiëren van variabelen in een taak en het gebruik ervan binnen taken.

variables:
  mySimpleVar: simple var value
  "my.dotted.var": dotted var value
  "my var with spaces": var with spaces value

steps:
- script: echo Input macro = $(mySimpleVar). Env var = %MYSIMPLEVAR%
  condition: eq(variables['agent.os'], 'Windows_NT')
- script: echo Input macro = $(mySimpleVar). Env var = $MYSIMPLEVAR
  condition: in(variables['agent.os'], 'Darwin', 'Linux')
- bash: echo Input macro = $(my.dotted.var). Env var = $MY_DOTTED_VAR
- powershell: Write-Host "Input macro = $(my var with spaces). Env var = $env:MY_VAR_WITH_SPACES"

Zie Voorwaarden opgeven voor informatie over het gebruik van een voorwaarde.

Werkplek

Wanneer u een agentpooltaak uitvoert, wordt er een werkruimte op de agent gemaakt. De werkruimte is een map waarin de bron wordt gedownload, stappen worden uitgevoerd en uitvoer wordt geproduceerd. Er kan naar de werkruimtemap worden verwezen in uw taak met behulp van Pipeline.Workspace een variabele. Onder deze indeling worden verschillende submappen gemaakt:

  • Build.SourcesDirectory is waar taken de broncode van de toepassing downloaden.
  • Build.ArtifactStagingDirectory is waar taken artefacten downloaden die nodig zijn voor de pijplijn of artefacten uploaden voordat ze worden gepubliceerd.
  • Build.BinariesDirectory is waar taken hun uitvoer schrijven.
  • Common.TestResultsDirectory is waar taken hun testresultaten uploaden.

De $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) worden altijd verwijderd en opnieuw gemaakt vóór elke build.

Wanneer u een pijplijn uitvoert op een zelf-hostende agent, worden standaard geen van de andere submappen dan $(Build.ArtifactStagingDirectory) en $(Common.TestResultsDirectory) tussen twee opeenvolgende uitvoeringen opgeschoond. Als gevolg hiervan kunt u incrementele builds en implementaties uitvoeren, mits taken worden geïmplementeerd om hiervan gebruik te maken. U kunt dit gedrag overschrijven met behulp van de workspace instelling voor de taak.

Belangrijk

De opties voor het opschonen van de werkruimte zijn alleen van toepassing op zelf-hostende agents. Taken worden altijd uitgevoerd op een nieuwe agent met door Microsoft gehoste agents.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Wanneer u een van de clean opties opgeeft, worden deze als volgt geïnterpreteerd:

  • outputs: Verwijderen Build.BinariesDirectory voordat u een nieuwe taak uitvoert.
  • resources: Verwijderen Build.SourcesDirectory voordat u een nieuwe taak uitvoert.
  • all: Verwijder de hele Pipeline.Workspace map voordat u een nieuwe taak uitvoert.
  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Notitie

Afhankelijk van de mogelijkheden van uw agent en de vraag naar pijplijnen, kan elke taak worden doorgestuurd naar een andere agent in uw zelf-hostende pool. Als gevolg hiervan krijgt u mogelijk een nieuwe agent voor volgende pijplijnuitvoeringen (of fasen of taken in dezelfde pijplijn), dus het niet opschonen is geen garantie dat volgende uitvoeringen, taken of fasen toegang hebben tot uitvoer van eerdere uitvoeringen, taken of fasen. U kunt agentmogelijkheden en pijplijnvereisten configureren om op te geven welke agents worden gebruikt om een pijplijntaak uit te voeren, maar tenzij er slechts één agent in de pool is die voldoet aan de vereisten, is er geen garantie dat volgende taken dezelfde agent gebruiken als eerdere taken. Zie Vereisten opgeven voor meer informatie.

Naast het opschonen van werkruimten kunt u ook opschonen configureren door de instelling Opschonen te configureren in de gebruikersinterface voor pijplijninstellingen. Wanneer de instelling Opschonen waar is, wat ook de standaardwaarde is, is deze gelijk aan het clean: true opgeven van elke uitcheckstap in uw pijplijn. Wanneer u opgeeft clean: true, wordt u uitgevoerd git clean -ffdx gevolgd door git reset --hard HEAD voordat Git wordt opgehaald. De instelling Opschonen configureren:

  1. Bewerk uw pijplijn, kies ...en selecteer Triggers.

    Triggers bewerken.

  2. Selecteer YAML, Bronnen ophalen en configureer de gewenste instelling Opschonen . De standaardwaarde is waar.

    Schone instelling.

Artefact downloaden

In dit voorbeeld van een YAML-bestand wordt het artefact WebSite gepubliceerd en wordt het artefact vervolgens gedownload naar $(Pipeline.Workspace). De implementatietaak wordt alleen uitgevoerd als de buildtaak is geslaagd.

# test and upload my code as an artifact named WebSite
jobs:
- job: Build
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - script: npm test
  - task: PublishBuildArtifacts@1
    inputs:
      pathtoPublish: '$(System.DefaultWorkingDirectory)'
      artifactName: WebSite

# download the artifact and deploy it only if the build job succeeded
- job: Deploy
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - checkout: none #skip checking out the default repository resource
  - task: DownloadBuildArtifacts@0
    displayName: 'Download Build Artifacts'
    inputs:
      artifactName: WebSite
      downloadPath: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Zie Voorwaarden opgeven voor informatie over het gebruik van dependsOn en voorwaarde.

Toegang tot OAuth-token

U kunt toestaan dat scripts die in een taak worden uitgevoerd, toegang hebben tot het huidige Azure Pipelines- of TFS OAuth-beveiligingstoken. Het token kan worden gebruikt om te verifiëren bij de REST API van Azure Pipelines.

Het OAuth-token is altijd beschikbaar voor YAML-pijplijnen. Deze moet expliciet worden toegewezen aan de taak of stap met behulp van env. Hier volgt een voorbeeld:

steps:
- powershell: |
    $url = "$($env:SYSTEM_TEAMFOUNDATIONCOLLECTIONURI)$env:SYSTEM_TEAMPROJECTID/_apis/build/definitions/$($env:SYSTEM_DEFINITIONID)?api-version=4.1-preview"
    Write-Host "URL: $url"
    $pipeline = Invoke-RestMethod -Uri $url -Headers @{
      Authorization = "Bearer $env:SYSTEM_ACCESSTOKEN"
    }
    Write-Host "Pipeline = $($pipeline | ConvertTo-Json -Depth 100)"
  env:
    SYSTEM_ACCESSTOKEN: $(system.accesstoken)

De volgende stap