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

YAML

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
  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.

Klassiek

Als u taken wilt toevoegen aan uw build-pijplijn, bewerkt u de pijplijn op de pagina Pijplijnen. Selecteer ... om een taak toe te voegen.

Als u taken wilt toevoegen aan uw release-pijplijn, bewerkt u de pijplijn vanuit pijplijnreleases>. Bekijk de fasetaken in de fase waar u uw taak wilt toevoegen. Selecteer ... om een taak toe te voegen.

Typen taken

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

YAML

• Agentpooltaken worden uitgevoerd op een agent in een agentpool.
• Servertaken worden uitgevoerd op de Azure DevOps Server.
• Containertaken worden uitgevoerd in een container op een agent in een agentpool. Zie Containertaken definiëren voor meer informatie over het kiezen van containers.

Klassiek

• Agentpooltaken worden uitgevoerd op een agent in een agentpool.
• Servertaken worden uitgevoerd op de Azure DevOps Server.
• Implementatiegroeptaken worden uitgevoerd op machines in een implementatiegroep. Deze taken zijn alleen beschikbaar in release-pijplijnen. Zie Implementatiegroeptaken voor meer informatie over het definiëren van groepen doelservers voor implementatie.

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.

YAML

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

Klassiek

U hebt de mogelijkheid om de vereisten in de pijplijn, in de taken of beide op te geven. Als u eisen opgeeft in zowel de pijplijn als in een taak, is de samenvoeging van de twee sets met vereisten vereist voor het systeem om een agent te selecteren.

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:

• Taak vertragen
• Azure Function-taak aanroepen
• REST API-taak aanroepen
• Handmatige validatietaak
• Publiceren naar Azure Service Bus-taak
• Azure Monitor-waarschuwingstaak opvragen
• Taak Werkitems opvragen

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.

YAML

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

Klassiek

U voegt een servertaak toe in de editor door ...' te selecteren op het pijplijnkanaal op het tabblad Taken van een pijplijn. De eigenschappen voor de servertaak worden weergegeven wanneer u de taak in de editor selecteert.

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.

YAML

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

Klassiek

Als u een nieuwe taak wilt toevoegen, selecteert u ...' op het pijplijnkanaal op het tabblad Taken van de pijplijn. De voorwaarden en volgorde van uitvoering voor een taak worden weergegeven wanneer u de taak in de editor selecteert.

Wanneer u meerdere taken in een build-pijplijn opgeeft, worden ze standaard parallel uitgevoerd. U kunt de volgorde opgeven waarin taken moeten worden uitgevoerd door afhankelijkheden tussen taken te configureren. Taakafhankelijkheden worden niet ondersteund in release-pijplijnen. Meerdere taken in een release-pijplijn worden op volgorde uitgevoerd.

De onderstaande pijplijn verdeelt bijvoorbeeld de algehele release-uitvoering in afzonderlijke uitvoeringstaken met behulp van twee agenttaken en een servertaak.

In het bovenstaande voorbeeld:

1. De taken in de eerste taak van de release worden uitgevoerd op een agent en, nadat deze taak is voltooid, wordt de agent vrijgegeven.

2. De servertaak bevat een handmatige interventietaak die wordt uitgevoerd op de Azure Pipelines of TFS. De taak wordt niet uitgevoerd op of vereist een agent of doelservers. De handmatige interventietaak geeft het bericht weer en wacht op een antwoord 'hervatten' of 'weigeren' van de gebruiker. Als in dit voorbeeld de geconfigureerde time-out is bereikt, wordt de implementatie automatisch geweigerd door de taak (stel de time-out in de sectie Besturingsopties in op nul als u geen geautomatiseerd antwoord wilt genereren).

3. Als de release wordt hervat, worden taken in de derde taak uitgevoerd, mogelijk op een andere agent. Als de release wordt geweigerd, wordt deze taak niet uitgevoerd en wordt de release gemarkeerd als mislukt.

Het is belangrijk om een aantal gevolgen van gefaseerde uitvoering te begrijpen:

• Voor elke taak kunnen verschillende agents worden gebruikt. Stel niet dat de status van een eerdere taak beschikbaar is tijdens volgende taken.

• De opties Doorgaan bij fout en Altijd uitvoeren voor taken in elke taak hebben geen effect op taken in volgende taken. Als u bijvoorbeeld Altijd uitvoeren instelt op een taak aan het einde van de eerste taak, wordt niet gegarandeerd dat taken in de volgende taken worden uitgevoerd.

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.

YAML

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

Klassiek

Gebruik de optie Deze taak uitvoeren op een agent- of servertaak om de taken alleen uit te voeren wanneer aan bepaalde voorwaarden wordt voldaan. Selecteer een vooraf gedefinieerde voorwaarde of selecteer 'aangepast' en voer een expressie in die waar of onwaar oplevert. Geneste expressies kunnen worden gebruikt en de expressies hebben toegang tot variabelen die beschikbaar zijn in de release-pijplijn.

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.

YAML

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

Klassiek

Selecteer de taak en geef vervolgens de time-outwaarde op.

Op het tabblad Opties kunt u standaardwaarden opgeven voor alle taken in de pijplijn. Als u een niet-nulwaarde opgeeft voor de time-out van de taak, overschrijft deze elke waarde die is opgegeven in de pijplijnopties. Als u een nulwaarde opgeeft, wordt de time-outwaarde uit de pijplijnopties gebruikt. Als de waarde van de pijplijn ook is ingesteld op nul, is er geen time-out.

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.

YAML

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

Klassiek

Als u meerdere taken wilt uitvoeren met de optie voor meervoudige configuratie, identificeert u een variabele met de naam een vermenigvuldiger en geeft u een lijst met waarden voor die vermenigvuldiger op. Er wordt een afzonderlijke taak uitgevoerd voor elke waarde in de lijst. Als u vermenigvuldigers wilt gebruiken voor het bouwen of implementeren, moet u het volgende doen:

• Definieer een of meer variabelen op het tabblad Variabelen van de pijplijn of in een variabelegroep. Elke variabele, in deze context bekend als een vermenigvuldigervariabele , moet worden gedefinieerd als een door komma's gescheiden lijst met de waarden die u afzonderlijk aan de agents wilt doorgeven.

• Voer de naam in van de vermenigvuldigervariabele, zonder de $ haakjes, als de waarde van de parameter Vermenigvuldigers . Het gebruik van een geheime variabele als vermenigvuldigervariabele wordt niet ondersteund.

• Als u de taak voor meer dan één vermenigvuldigervariabele wilt uitvoeren, voert u de namen van variabelen in als een door komma's gescheiden lijst, zodat u de $ en haakjes voor elke variabele weglaat.

• Als u het aantal agents dat tijdens de implementatie wordt gebruikt wilt beperken tot een getal kleiner dan u voor uw abonnement hebt geconfigureerd, voert u die waarde in als de parameter Maximum aantal agents .

U kunt bijvoorbeeld twee variabelen met de naam Locatie en Browser als volgt definiëren:

• Location = US,Europe
• Browser = IE,Chrome,Edge,Firefox

Met de volgende configuratie wordt de implementatie acht keer uitgevoerd met maximaal vier agents tegelijk:

• Multipliers = Location,Browser
• Maximum aantal agents = 4

Met meerdere configuraties kunt u meerdere taken uitvoeren, elk met een andere waarde voor een of meer variabelen (vermenigvuldigers). Als u dezelfde taak op meerdere agents wilt uitvoeren, kunt u de optie voor parallelle uitvoering met meerdere agents gebruiken. Het bovenstaande voorbeeld van testsegmentering kan worden uitgevoerd via de optie voor meerdere agents.

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.

YAML

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

Klassiek

Geef de optie voor meerdere agents op voor een agenttaak om segmentering toe te passen. De taak wordt zo vaak verzonden als het aantal agents dat u opgeeft, en de variabelen System.JobPositionInPhase en System.TotalJobsInPhase worden automatisch ingesteld in elke taak.

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.

YAML

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"

Klassiek

Taakvariabelen worden nog niet ondersteund in de webeditor.

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.

YAML

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.

   

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

   

Klassiek

Wanneer u een pijplijn uitvoert op een zelf-hostende agent, worden standaard geen van de submappen tussen twee opeenvolgende uitvoeringen opgeschoond. Als gevolg hiervan kunt u incrementele builds en implementaties uitvoeren, mits taken hiervoor zijn geïmplementeerd. U kunt dit gedrag echter overschrijven met behulp van de Clean build optie onder Get sources taak. De opties variëren, afhankelijk van het type opslagplaats dat u gebruikt.

• GitHub
• Azure Repos Git
• TFVC

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.

YAML

# 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()

Klassiek

In een release-pijplijn kunt u ervoor kiezen om het downloaden van artefacten tijdens de taakuitvoering over te slaan. Gebruik deze optie als u uw eigen aangepaste logica wilt implementeren voor het downloaden van artefacten met behulp van taken of als de taken in een bepaalde taak niet afhankelijk zijn van de artefacten.

U kunt er ook voor kiezen om specifieke artefacten te downloaden tijdens de taakuitvoering in een release. Gebruik deze optie als de taken in een bepaalde taak alleen afhankelijk zijn van specifieke artefacten.

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.

YAML

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)

Klassiek

Selecteer de optie Scripts toestaan voor toegang tot OAuth-token in de besturingsopties voor de taak. Het token is beschikbaar als de omgevingsvariabele SYSTEM_ACCESSTOKEN.

De volgende stap

• Taken voor implementatiegroepen
• Voorwaarden