Ange jobb i din pipeline

I det enklaste fallet har en pipeline ett enda jobb. I så fall behöver du inte uttryckligen använda nyckelordet job om du inte använder en mall. Du kan ange stegen direkt i YAML-filen.

Den här YAML-filen har ett jobb som körs på en Microsoft-värdbaserad agent och utdata Hello world.

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

Du kanske vill ange fler egenskaper för jobbet. I så fall kan du använda nyckelordet job .

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

Din pipeline kan ha flera jobb. I så fall använder du nyckelordet jobs .

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

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

Din pipeline kan ha flera steg, var och en med flera jobb. I så fall använder du nyckelordet stages .

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

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

Den fullständiga syntaxen för att ange ett jobb är:

- 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

Den fullständiga syntaxen för att ange ett jobb är:

- 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

Om det primära syftet med jobbet är att distribuera din app (i stället för att skapa eller testa din app) kan du använda en särskild typ av jobb som kallas distributionsjobb.

Syntaxen för ett distributionsjobb är:

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

Även om du kan lägga till steg för distributionsuppgifter i en jobrekommenderar vi att du i stället använder ett distributionsjobb. Ett distributionsjobb har några fördelar. Du kan till exempel distribuera till en miljö, vilket inkluderar fördelar som att kunna se historiken för det du har distribuerat.

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

Eller flera krav:

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

Den fullständiga syntaxen för att ange ett serverjobb är:

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

Du kan också använda den förenklade syntaxen:

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

Syntaxen för att definiera flera jobb och deras beroenden är:

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

Exempeljobb som skapas sekventiellt:

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

Exempeljobb som skapas parallellt (inga beroenden):

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

Exempel på fläkt ut:

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

Exempel på inaktivering:

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

När du anger flera jobb i en byggpipeline körs de parallellt som standard. Du kan ange i vilken ordning jobben måste köras genom att konfigurera beroenden mellan jobb. Jobbberoenden stöds inte i versionspipelines. Flera jobb i en versionspipeline körs i följd.

Exempel för att köra ett jobb baserat på statusen för att köra ett tidigare jobb:

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

Exempel på användning av ett anpassat villkor:

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

Du kan ange att ett jobb ska köras baserat på värdet för en utdatavariabel som angetts i ett tidigare jobb. I det här fallet kan du bara använda variabler som angetts i direkt beroende jobb:

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

Använd alternativet Kör det här jobbet på en agent eller ett serverjobb för att endast köra aktiviteterna när specifika villkor uppfylls. Välj ett fördefinierat villkor eller välj "anpassad" och ange ett uttryck som utvärderas till sant eller falskt. Kapslade uttryck kan användas och uttrycken kan komma åt variabler som är tillgängliga i versionspipelinen.

timeoutInMinutes Tillåter att en gräns anges för jobbkörningstiden. När det inte anges är standardvärdet 60 minuter. När 0 anges används den maximala gränsen (beskrivs ovan).

cancelTimeoutInMinutes Tillåter att en gräns anges för jobbets avbrutna tid när distributionsaktiviteten är inställd på att fortsätta köras om en tidigare aktivitet misslyckades. När det inte anges är standardvärdet 5 minuter. Värdet ska vara i intervallet 1 till 35790 minuter.

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

Strategin matrix gör att ett jobb kan skickas flera gånger med olika variabeluppsättningar. Taggen maxParallel begränsar mängden parallellitet. Följande jobb skickas tre gånger med värdena för Plats och Webbläsare angivna. Men bara två jobb körs samtidigt.

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

Du kan också använda utdatavariabler för att generera en matris. Detta kan vara praktiskt om du behöver generera matrisen med hjälp av ett skript.

matrix accepterar ett körningsuttryck som innehåller ett strängifierat JSON-objekt. Det JSON-objektet måste, när det expanderas, matcha matrissyntaxen. I exemplet nedan har vi hårdkodat JSON-strängen, men den kan genereras av ett skriptspråk eller kommandoradsprogram.

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

Strategin parallel gör att ett jobb kan dupliceras många gånger. Variabler System.JobPositionInPhase och System.TotalJobsInPhase läggs till i varje jobb. Variablerna kan sedan användas i skripten för att dela upp arbetet mellan jobben. Se Parallell och flera körningar med agentjobb.

Följande jobb skickas fem gånger med värdena System.JobPositionInPhase för och System.TotalJobsInPhase inställt på rätt sätt.

jobs:
- job: Test
  strategy:
    parallel: 5

Här är ett exempel på hur du definierar variabler i ett jobb och använder dem i aktiviteter.

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"

Och $(Build.ArtifactStagingDirectory) $(Common.TestResultsDirectory) tas alltid bort och återskapas före varje version.

När du kör en pipeline på en lokalt installerad agent rensas som standard ingen annan underkatalog än $(Build.ArtifactStagingDirectory) och $(Common.TestResultsDirectory) rensas mellan två på varandra följande körningar. Därför kan du göra inkrementella byggen och distributioner, förutsatt att uppgifter implementeras för att använda det. Du kan åsidosätta det här beteendet med hjälp av workspace inställningen för jobbet.

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

När du anger något av clean alternativen tolkas de på följande sätt:

• outputs: Ta bort Build.BinariesDirectory innan du kör ett nytt jobb.
• resources: Ta bort Build.SourcesDirectory innan du kör ett nytt jobb.
• all: Ta bort hela Pipeline.Workspace katalogen innan du kör ett nytt jobb.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Förutom att rensa arbetsytan kan du även konfigurera rensning genom att konfigurera inställningen Rensa i användargränssnittet för pipelineinställningar. När inställningen Rensa är true, som också är dess standardvärde, motsvarar den att ange för varje utcheckningssteg clean: true i pipelinen. När du anger clean: truekör git clean -ffdx du följt av git reset --hard HEAD innan git-hämtningen. Så här konfigurerar du inställningen Rensa :

1. Redigera din pipeline, välj ...och välj Utlösare.

   

2. Välj YAML, Hämta källor och konfigurera önskad clean-inställning . Standardvärdet är sant.

   

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

Du kan också välja att ladda ned specifika artefakter under jobbkörningen i en version. Använd det här alternativet om aktiviteterna i ett visst jobb endast förlitar sig på specifika artefakter.

OAuth-token är alltid tillgänglig för YAML-pipelines. Den måste uttryckligen mappas till uppgiften eller steget med hjälp av env. Här är ett exempel:

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)