Angeben von Aufträgen in Ihrer Pipeline

Im einfachsten Fall umfasst eine Pipeline einen einzelnen Auftrag. In diesem Fall müssen Sie das job Schlüsselwort nicht ausdrücklich verwenden, es sei denn, Sie verwenden eine Vorlage. Sie können die Schritte direkt in Ihrer YAML-Datei angeben.

Diese YAML-Datei enthält einen Auftrag, der auf einem von Microsoft gehosteten Agent ausgeführt wird und Hello world ausgibt.

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

Möglicherweise möchten Sie zusätzliche Eigenschaften für diesen Auftrag angeben. Dazu können Sie das job-Schlüsselwort verwenden.

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

Ihre Pipeline umfassen möglicherweise mehrere Aufträge. Verwenden Sie in diesem Fall das jobs-Schlüsselwort.

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

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

Ihre Pipeline kann mehrere Stages mit jeweils mehreren Aufträgen umfassen. Verwenden Sie in diesem Fall das stages-Schlüsselwort.

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

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

Die vollständige Syntax zum Angeben eines Auftrags lautet wie folgt:

- 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

Die vollständige Syntax zum Angeben eines Auftrags lautet wie folgt:

- 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

Wenn der Hauptzweck Ihres Auftrags darin besteht, Ihre App bereitzustellen (im Gegensatz zum Erstellen oder Testen Ihrer App), dann können Sie einen speziellen Auftragstyp namens Bereitstellungsauftrag verwenden.

Die Syntax für einen Bereitstellungsauftrag lautet wie folgt:

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

Obwohl Sie Schritte für Bereitstellungsaufgaben in einem job hinzufügen können, empfehlen wir, stattdessen einen Bereitstellungsauftrag zu verwenden. Ein Bereitstellungsauftrag bietet verschiedene Vorteile. Sie können die Bereitstellung beispielsweise in einer Umgebung vornehmen. Dies hat den Vorteil, dass Sie den Verlauf der durchgeführten Bereitstellung anzeigen können.

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

Oder mehrere Anforderungen:

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

Die vollständige Syntax zum Angeben eines Serverauftrags lautet wie folgt:

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

Sie können auch die vereinfachte Syntax verwenden:

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

Die Syntax zum Definieren mehrerer Aufträge und ihrer Abhängigkeiten lautet wie folgt:

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

Beispielaufträge, die sequenziell erstellt werden:

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

Beispielaufträge, die parallel erstellt werden (keine Abhängigkeiten):

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

Beispiel für das Auffächern nach außen:

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

Beispiel für das Auffächern nach innen:

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

Wenn Sie mehrere Aufträge in einer Buildpipeline angeben, werden diese standardmäßig parallel ausgeführt. Sie können die Reihenfolge festlegen, in der Aufträge ausgeführt werden müssen, indem Sie Abhängigkeiten zwischen Aufträgen konfigurieren. Auftragsabhängigkeiten werden in Releasepipelines nicht unterstützt. In einer Releasepipeline werden mehrere Aufträge nacheinander ausgeführt.

Beispiel für die Ausführung eines Auftrags basierend auf dem Status der Ausführung eines vorherigen Auftrags:

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

Beispiel für die Verwendung einer benutzerdefinierten Bedingung:

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

Sie können angeben, dass ein Auftrag basierend auf dem Wert einer in einem vorherigen Auftrag festgelegten Ausgabevariablen ausgeführt wird. In diesem Fall können Sie nur Variablen verwenden, die in direkt abhängigen Aufträgen festgelegt wurden:

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

Verwenden Sie die Option Diesen Auftrag ausführen für einen Agent- oder Serverauftrag, um die Aufgaben nur auszuführen, wenn bestimmte Bedingungen erfüllt sind. Wählen Sie eine vordefinierte Bedingung aus, oder klicken Sie auf „Benutzerdefiniert“, und geben Sie einen Ausdruck ein, der als true oder false ausgewertet wird. Sie können geschachtelte Ausdrücke verwenden, und die Ausdrücke können auf Variablen zugreifen, die in der Releasepipeline verfügbar sind.

Mit timeoutInMinutes können Sie ein Limit für die Ausführungsdauer des Auftrags festlegen. Sofern nicht angegeben, beträgt der Standardwert 60 Minuten. Wenn Sie 0 angeben, wird die Höchstgrenze verwendet (wie oben beschrieben).

Mit cancelTimeoutInMinutes können Sie einen Grenzwert für die Abbruchzeit des Auftrags festlegen, wenn die Bereitstellungsaufgabe so konfiguriert ist, dass sie auch nach dem Fehlschlagen einer vorherigen Aufgabe weiter ausgeführt wird. Sofern nicht angegeben, beträgt der Standardwert 5 Minuten. Der Wert sollte zwischen 1 und 35790 Minuten liegen.

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

Die matrix-Strategie ermöglicht es, einen Auftrag mehrmals mit unterschiedlichen Variablensätzen zu senden. Das Tag maxParallel schränkt den Umfang der Parallelität ein. Der folgende Auftrag wird dreimal mit den angegebenen Werten für Standort und Browser gesendet. Es werden jedoch jeweils nur zwei Aufträge gleichzeitig ausgeführt.

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

Es ist auch möglich, zum Generieren einer Matrix Ausgabevariablen zu verwenden. Dies kann nützlich sein, wenn Sie die Matrix mithilfe eines Skripts generieren müssen.

matrix akzeptiert einen Laufzeitausdruck, der ein als Zeichenfolge dargestelltes JSON-Objekt enthält. Dieses JSON-Objekt muss bei Erweiterung mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel wurde die JSON-Zeichenfolge hartcodiert, aber sie könnte auch durch eine Skriptsprache oder ein Befehlszeilenprogramm generiert werden.

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

Die parallel-Strategie ermöglicht es, einen Auftrag mehrmals zu duplizieren. Die Variablen System.JobPositionInPhase und System.TotalJobsInPhase werden jedem Auftrag hinzugefügt. Anschließend können die Variablen in Ihren Skripts verwendet werden, um die Arbeit auf die einzelnen Aufträge zu verteilen. Weitere Informationen finden Sie unter Parallele und mehrfache Ausführung mithilfe von Agentaufträgen.

Der folgende Auftrag wird mit entsprechender Festlegung der Werte von System.JobPositionInPhase und System.TotalJobsInPhase fünfmal gesendet.

jobs:
- job: Test
  strategy:
    parallel: 5

Das folgende Beispiel zeigt, wie Sie Variablen in einem Auftrag definieren und sie in Aufgaben verwenden.

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"

$(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) werden immer gelöscht und vor jedem Build neu erstellt.

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird zwischen zwei aufeinanderfolgenden Ausführungen standardmäßig (mit Ausnahme von $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory)) keines der Unterverzeichnisse bereinigt. Dadurch können Sie inkrementelle Builds und Bereitstellungen durchführen, sofern Aufgaben implementiert sind, die diese Möglichkeit nutzen. Sie können dieses Verhalten überschreiben, indem Sie die Einstellung workspace für den Auftrag verwenden.

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

Wenn Sie eine der clean-Optionen angeben, werden diese wie folgt interpretiert:

• outputs: Löschung von Build.BinariesDirectory vor dem Ausführen eines neuen Auftrags
• resources: Löschung von Build.SourcesDirectory vor dem Ausführen eines neuen Auftrags
• all: Löschung des gesamten Verzeichnisses Pipeline.Workspace vor dem Ausführen eines neuen Auftrags

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

Zusätzlich zur Arbeitsbereichbereinigung können Sie die Bereinigung auch über die Einstellung Bereinigung in der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung Bereinigen auf true festgelegt ist, dies ist der Standardwert, entspricht sie der Angabe von clean: true für jeden Check-Out-Schritt in Ihrer Pipeline. Wenn Sie clean: true angeben, führen Sie vor dem git-Abruf git clean -ffdx gefolgt von git reset --hard HEAD aus. So konfigurieren Sie die Einstellung Bereinigen

1. Bearbeiten Sie Ihre Pipeline, wählen Sie ... und dann Trigger aus.

   

2. Wählen Sie YAML und dann Quellen abrufen aus, und konfigurieren Sie die gewünschte Einstellung für Bereinigen. Der Standardwert ist true.

   

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

Alternativ können Sie bestimmte Artefakte während der Auftragsausführung in einem Release herunterladen. Verwenden Sie diese Option, wenn die Aufgaben in einem bestimmten Auftrag nur auf bestimmten Artefakten basieren.

Das OAuth-Token ist für YAML-Pipelines immer verfügbar. Er muss der Aufgabe oder dem Schritt explizit mit env zugewiesen werden. Ein Beispiel:

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)