Freigeben über


Angeben von Aufträgen in Ihrer Pipeline

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

Sie können Ihre Pipeline nach Aufträgen organisieren. Jede Pipeline umfasst mindestens einen Auftrag. Ein Auftrag besteht aus einer Reihe von Schritten, die nacheinander als eine Einheit ausgeführt werden. Anders ausgedrückt: Ein Auftrag ist die kleinste Arbeitseinheit, die zur Ausführung geplant werden kann.

Informationen zu den wichtigsten Konzepten und Komponenten, aus denen eine Pipeline besteht, finden Sie unter Schlüsselkonzepte für neue Azure Pipelines-Benutzer.

Azure Pipelines unterstützt keine Auftragspriorität für YAML-Pipelines. Um zu steuern, wann Aufträge ausgeführt werden, können Sie Bedingungen und Abhängigkeiten angeben.

Definieren eines einzelnen Auftrags

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.

Auftragstypen

Es gibt verschiedene Auftragstypen, je nachdem, wo sie ausgeführt werden.

  • Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
  • Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.
  • Containeraufträge werden in einem Container auf einem Agent in einem Agentpool ausgeführt. Weitere Informationen zum Auswählen von Containern finden Sie unter Definieren von Containeraufträgen.
  • Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
  • Serveraufträge werden in der Azure DevOps Server-Instanz ausgeführt.

Agentpoolaufträge

Dies ist der häufigste Auftragstyp, der auf einem Agent in einem Agentpool ausgeführt wird.

  • Wenn Sie von Microsoft gehostete Agents verwenden, wird für jeden Auftrag in einer Pipeline ein neuer Agent bereitgestellt.
  • Geben Sie mithilfe von Anforderungen für selbstgehostete Agents an, über welche Funktionen ein Agent verfügen muss, um Ihren Auftrag auszuführen. Möglicherweise wird Ihnen für aufeinanderfolgende Aufträge derselbe Agent zugeteilt. Dies hängt davon ab, ob in Ihrem Agentpool mehrere Agents vorhanden sind, die den Anforderungen Ihrer Pipeline entsprechen. Wenn in Ihrem Pool nur ein Agent vorhanden ist, der den Anforderungen der Pipeline entspricht, wartet die Pipeline, bis dieser Agent verfügbar ist.

Hinweis

Anforderungen und Funktionen sind für die Verwendung mit selbstgehosteten Agents konzipiert, damit Aufträge einem Agent zugewiesen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie von Microsoft gehostete Agents verwenden, wählen Sie ein Image für den Agent aus, das den Anforderungen des Auftrags entspricht. Obwohl es möglich ist, einem von Microsoft gehosteten Agent Funktionen hinzuzufügen, müssen Sie bei von Microsoft gehosteten Agents keine Funktionen verwenden.

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

Erfahren Sie mehr über Agentfunktionen.

Serveraufträge

Die Aufgaben in einem Serverauftrag werden vom Server (Azure Pipelines oder TFS) orchestriert und auf diesem ausgeführt. Für einen Serverauftrag sind weder ein Agent noch Zielcomputer erforderlich. Derzeit werden nur einige wenige Aufgaben in einem Serverauftrag unterstützt. Die maximale Zeit für einen Serverauftrag beträgt 30 Tage.

Unterstützte Aufgaben für Aufträge ohne Agent

Derzeit werden für Aufträge ohne Agent standardmäßig nur die folgenden Aufgaben unterstützt:

Da Aufgaben erweiterbar sind, können Sie mithilfe von Erweiterungen weitere Aufgaben ohne Agent hinzufügen. Das Standardtimeout für Aufträge ohne Agent beträgt 60 Minuten.

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

Abhängigkeiten

Wenn Sie mehrere Aufträge in einer einzigen Stage definieren, können Sie Abhängigkeiten zwischen diesen Aufträgen festlegen. Pipelines müssen mindestens einen Auftrag ohne Abhängigkeiten enthalten. Standardmäßig werden Azure DevOps-YAML-Pipelineaufträge parallel ausgeführt – es sei denn, der Wert dependsOn ist festgelegt.

Hinweis

Jeder Agent kann jeweils nur einen Auftrag ausführen. Um mehrere Aufträge parallel auszuführen, müssen Sie mehrere Agents konfigurieren. Außerdem müssen genügend Parallelaufträge vorhanden sein.

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

Bedingungen

Sie können die Bedingungen festlegen, unter denen jeder Auftrag ausgeführt wird. Standardmäßig wird ein Auftrag ausgeführt, wenn er von keinem anderen Auftrag abhängt oder wenn alle Aufträge, von denen er abhängt, abgeschlossen wurden und erfolgreich waren. Sie können dieses Verhalten anpassen, indem Sie die Ausführung eines Auftrags erzwingen, auch wenn ein vorheriger Auftrag fehlschlägt, oder indem Sie eine benutzerdefinierte Bedingung angeben.

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

Zeitlimits

Damit keine Ressourcen verbraucht werden, wenn Ihr Auftrag nicht reagiert oder zu lange wartet, empfiehlt es sich, ein Limit für die Ausführungsdauer Ihres Auftrags festzulegen. Verwenden Sie die Timeouteinstellung für den Auftrag, um ein Limit in Minuten für die Auftragsausführung festzulegen. Wenn Sie den Wert auf 0 festlegen, bedeutet dies, dass der Auftrag folgendermaßen ausgeführt werden kann:

  • Ohne Zeitlimit auf selbstgehosteten Agents
  • Für 360 Minuten (6 Stunden) auf von Microsoft gehosteten Agents mit einem öffentlichen Projekt und einem öffentlichen Repository
  • Für 60 Minuten auf von Microsoft gehosteten Agents mit einem privaten Projekt oder privaten Repository (sofern keine zusätzliche Kapazität erworben wird)

Der Timeoutzeitraum beginnt, wenn die Auftragsausführung gestartet wird. Die Zeit, in der die Aufgabe sich in der Warteschlange befindet oder auf einen Agent wartet, wird nicht berücksichtigt.

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

Timeouts haben die folgende Rangebene.

  1. Bei von Microsoft gehosteten Agents sind Aufträge begrenzt, wie lange sie basierend auf dem Projekttyp ausgeführt werden können und ob sie mit einem kostenpflichtigen parallelen Auftrag ausgeführt werden. Wenn das von Microsoft gehostete Auftragstimeoutintervall verstrichen ist, wird der Auftrag beendet. In von Microsoft gehosteten Agents können Aufträge nicht länger als dieses Intervall ausgeführt werden, unabhängig von Zeitüberschreitungen auf Auftragsebene, die im Auftrag angegeben sind.
  2. Das auf Auftragsebene konfigurierte Timeout gibt die maximale Dauer des auszuführenden Auftrags an. Wenn das Zeitüberschreitungsintervall der Auftragsebene verstrichen ist, wird der Auftrag beendet. Wenn der Auftrag auf einem von Microsoft gehosteten Agent ausgeführt wird, hat das Festlegen des Zeitlimits für die Auftragsebene auf ein Intervall größer als das in Microsoft gehostete Zeitlimit für die Auftragsebene keine Auswirkung, und das von Microsoft gehostete Zeitlimit wird verwendet.
  3. Sie können das Timeout für jede Aufgabe auch einzeln festlegen. Weitere Informationen finden Sie unter Aufgabensteuerungsoptionen. Wenn das Zeitüberschreitungsintervall auf Auftragsebene vor Abschluss der Aufgabe verstrichen ist, wird der ausgeführte Auftrag beendet, auch wenn der Vorgang mit einem längeren Timeoutintervall konfiguriert ist.

Konfiguration mit mehreren Aufträgen

Ausgehend von einem einzigen Auftrag, den Sie erstellen, können Sie mehrere Aufträge parallel auf mehreren Agents ausführen. Beispiele hierfür sind:

  • Builds mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel erstellen. Sie könnten zum Beispiel eine Visual C++-App sowohl für debug- als auch für release-Konfigurationen auf den Plattformen x86 und x64 erstellen. Weitere Informationen finden Sie unter Visual Studio Build – mehrere Konfigurationen für mehrere Plattformen.

  • Bereitstellungen mit mehreren Konfigurationen: Sie können mehrere Bereitstellungen parallel ausführen, z. B. in verschiedenen geografischen Regionen.

  • Tests mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel testen.

  • Bei Verwendung mehrerer Konfigurationen wird immer mindestens ein Auftrag generiert, selbst wenn eine Variable für mehrere Konfigurationen leer ist.

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

Hinweis

Namen von Matrixkonfigurationen (wie US_IE oben) dürfen nur Buchstaben des lateinischen Alphabets (A–Z, a–z), Ziffern und Unterstriche enthalten (_). Der Name muss mit einem Buchstaben beginnen. Außerdem darf der Name höchstens 100 Zeichen umfassen.

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

Aufteilen

Mit einem Agentauftrag können Sie eine Reihe von Tests parallel durchführen. Sie können zum Beispiel eine große Sammlung von 1.000 Tests auf einem einzigen Agent ausführen. Alternativ können Sie zwei Agents verwenden und auf jedem von ihnen 500 Tests parallel ausführen.

Damit Sie die Aufteilung nutzen können, müssen die Aufgaben im Auftrag wissen, welchem Segment sie angehören.

Die Visual Studio-Testaufgabe ist eine solche Aufgabe, die die Aufteilung von Tests unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie die Visual Studio-Testaufgabe parallel auf diesen Agents ausgeführt werden soll.

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

Auftragsvariablen

Wenn Sie YAML verwenden, können Variablen für den Auftrag angegeben werden. Die Variablen können mit der Makrosyntax $(Variablenname) an Aufgabeneingaben übergeben werden oder innerhalb eines Skripts mithilfe der Stagevariablen aufgerufen werden.

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"

Informationen zur Verwendung einer Bedingung finden Sie unter Angeben von Bedingungen.

Arbeitsbereich

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich für den Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in das der Quellcode heruntergeladen wird, in dem Schritte ausgeführt und Ausgaben erzeugt werden. Das Verzeichnis für den Arbeitsbereich kann in Ihrem Auftrag über die Variable Pipeline.Workspace referenziert werden. In diesem werden verschiedene Unterverzeichnisse erstellt:

  • Build.SourcesDirectory: In dieses Unterverzeichnis laden Aufgaben den Quellcode der Anwendung herunter.
  • Build.ArtifactStagingDirectory ist wo Aufgaben Artefakte herunterladen, die für die Pipeline benötigt werden oder Artefakte uploaden bevor sie veröffentlicht werden.
  • Build.BinariesDirectory: In dieses Unterverzeichnis schreiben Aufgaben ihre Ausgaben.
  • Common.TestResultsDirectory: In dieses Unterverzeichnis laden Aufgaben ihre Testergebnisse hoch.

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

Wichtig

Die Optionen zum Bereinigen des Arbeitsbereichs gelten nur für selbstgehostete Agents. Wenn Sie von Microsoft gehostete Agents verwenden, werden Aufträge immer auf einem neuen Agent ausgeführt.

- 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

Hinweis

Abhängig von den Funktionen Ihres Agents und den Anforderungen der Pipeline kann jeder Auftrag an einen anderen Agent in Ihrem selbstgehosteten Pool weitergeleitet werden. Infolgedessen wird für nachfolgende Pipelineausführungen (oder Stages oder Aufträge in derselben Pipeline) möglicherweise ein neuer Agent abgerufen. Keine Bereinigung ist also keine Garantie dafür, dass nachfolgende Ausführungen, Aufträge oder Phasen auf die Ausgaben vorheriger Ausführungen, Aufträge oder Stages zugreifen können. Sie können Agentfunktionen und Pipelineanforderungen konfigurieren, um festzulegen, welche Agents für die Ausführung eines Pipelineauftrags verwendet werden. Sofern sich jedoch nicht nur ein einziger Agent im Pool befindet, der die Anforderungen erfüllt, gibt es keine Garantie dafür, dass nachfolgende Aufträge denselben Agent verwenden wie vorherige Aufträge. Weitere Informationen finden Sie unter Angeben von Anforderungen.

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.

    Bearbeiten von Triggern

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

    Einstellung „Bereinigen“

Artefaktdownload

Diese YAML-Beispieldatei veröffentlicht das Artefakt WebSite und lädt das Artefakt dann nach $(Pipeline.Workspace) herunter. Der Bereitstellungsauftrag wird nur ausgeführt, wenn der Buildauftrag erfolgreich ist.

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

Informationen zur Verwendung vondependsOn und Bedingung finden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können den in einem Auftrag ausgeführten Skripts erlauben, auf das aktuelle Azure Pipelines- oder TFS-OAuth-Sicherheitstoken zuzugreifen. Das Token kann zur Authentifizierung bei der Azure Pipelines-REST-API verwendet werden.

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)

Nächste Schritte