Angeben von Aufträgen in Ihrer Pipeline

Azure DevOps Services | Azure DevOps Server 2022 – Azure DevOps Server 2019 | TFS 2018

Hinweis

In Microsoft Team Foundation Server (TFS) 2018 und früheren Versionen werden Build- und Release-Pipelines als Definitionen bezeichnet, Ausführungen werden als Builds bezeichnet, Dienstverbindungen werden als Dienstendpunkte bezeichnet, Stages werden als Umgebungen bezeichnet und Aufträge werden als Phasen bezeichnet.

Sie können Ihre Pipeline in Aufträgen organisieren. Jede Pipeline verfügt über mindestens einen Auftrag. Ein Auftrag ist eine Reihe von Schritten, die sequenziell als Einheit ausgeführt werden. Mit anderen Worten, ein Auftrag ist die kleinste Arbeitseinheit, die für die Ausführung geplant werden kann.

Sie können Ihre Build- oder Releasepipeline in Aufträgen organisieren. Jede Pipeline verfügt über mindestens einen Auftrag. Ein Auftrag ist eine Reihe von Schritten, die sequenziell als Einheit ausgeführt werden. Mit anderen Worten, ein Auftrag ist die kleinste Arbeitseinheit, die für die Ausführung geplant werden kann.

Hinweis

Sie müssen TFS 2018.2 installieren, um Aufträge in Buildprozessen zu verwenden. In TFS 2018 RTM können Sie Aufträge in Releasebereitstellungsprozessen verwenden.

Definieren eines einzelnen Auftrags

Im einfachsten Fall verfügt eine Pipeline über einen einzelnen Auftrag. In diesem Fall müssen Sie das job Schlüsselwort nicht explizit 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 Microsoft gehosteten Agent ausgeführt wird und ausgibtHello world.

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

Sie können zusätzliche Eigenschaften für diesen Auftrag angeben. In diesem Fall können Sie das job Schlüsselwort verwenden.

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

Ihre Pipeline verfügt möglicherweise über 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 Phasen mit jeweils mehreren Aufträgen aufweisen. 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:

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

- 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 die primäre Absicht Ihres Auftrags darin besteht, Ihre App bereitzustellen (anstatt Ihre App zu erstellen oder zu testen), können Sie einen speziellen Typ von Auftrag namens Bereitstellungsauftrag verwenden.

Die Syntax für einen Bereitstellungsauftrag lautet:

- 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 jobhinzufügen können, wird empfohlen, stattdessen einen Bereitstellungsauftrag zu verwenden. Ein Bereitstellungsauftrag hat einige Vorteile. Beispielsweise können Sie eine Bereitstellung in einer Umgebung durchführen, die Vorteile wie die Möglichkeit bietet, den Verlauf ihrer Bereitstellung anzuzeigen.

YAML wird in TFS nicht unterstützt.

Auftragstypen

Aufträge können unterschiedlich sein, 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 werden auf einem Agent im Agentpool ausgeführt. Diese Aufträge sind in Build- und Releasepipelines verfügbar.
  • Serveraufträge werden unter TFS ausgeführt. Diese Aufträge sind in Build- und Releasepipelines verfügbar.
  • Bereitstellungsgruppenaufträge werden auf Computern in einer Bereitstellungsgruppe ausgeführt. Diese Aufträge sind nur in Releasepipelines verfügbar.

Agentpoolaufträge

Dies sind die häufigsten Arten von Aufträgen, die auf einem Agent in einem Agent-Pool ausgeführt werden.

  • Bei Verwendung Microsoft gehosteter Agents erhält jeder Auftrag in einer Pipeline einen neuen Agent.
  • Verwenden Sie Anforderungen mit selbstgehosteten Agents, um anzugeben, welche Funktionen ein Agent zum Ausführen Ihres Auftrags haben muss. Möglicherweise erhalten Sie denselben Agent für aufeinanderfolgende Aufträge, je nachdem, ob in Ihrem Agentpool mehrere Agent 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, sodass Aufträge mit einem Agent abgeglichen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie Microsoft-gehosteten Agents verwenden, wählen Sie ein Image für den Agent aus, das den Anforderungen des Auftrags entspricht. Obwohl es möglich ist, einem Microsoft gehosteten Agent Funktionen hinzuzufügen, müssen Sie keine Funktionen mit Microsoft gehosteten Agents 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

YAML wird in TFS nicht unterstützt.

Erfahren Sie mehr über Agentfunktionen.

Serveraufträge

Aufgaben in einem Serverauftrag werden vom Server (Azure Pipelines oder TFS) orchestriert und auf dem Server ausgeführt. Für einen Serverauftrag ist kein Agent oder keine Zielcomputer erforderlich. Derzeit werden nur wenige Aufgaben in einem Serverauftrag unterstützt.

Unterstützte Aufgaben ohne Agent

Derzeit werden nur die folgenden Aufgaben sofort einsatzbereit für Aufträge ohne Agent unterstützt:

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

Die vollständige Syntax zum Angeben eines Serverauftrags lautet:

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

YAML wird in TFS nicht unterstützt.

Abhängigkeiten

Wenn Sie mehrere Aufträge in einer einzelnen Phase definieren, können Sie Abhängigkeiten zwischen ihnen angeben. Pipelines müssen mindestens einen Auftrag ohne Abhängigkeiten enthalten.

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 benötigen Sie genügend parallele Aufträge.

Die Syntax zum Definieren mehrerer Aufträge und deren Abhängigkeiten lautet:

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:

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 Einfächern:

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

YAML wird in TFS nicht unterstützt.

Bedingungen

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

Beispiel zum Ausführen 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/master'))
  steps:
  - script: echo this only runs for master

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

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

YAML wird in TFS nicht unterstützt.

Zeitlimits

Um zu vermeiden, dass Ressourcen in Anspruch genommen werden, wenn Ihr Auftrag nicht reagiert oder zu lange wartet, empfiehlt es sich, ein Limit festzulegen, wie lange Ihr Auftrag ausgeführt werden darf. Verwenden Sie die Einstellung für das Auftragstimeout, um den Grenzwert in Minuten für die Ausführung des Auftrags anzugeben. Das Festlegen des Werts auf 0 bedeutet, dass der Auftrag ausgeführt werden kann:

  • Forever für selbstgehostete Agents
  • 360 Minuten (6 Stunden) auf Microsoft gehosteten Agents mit einem öffentlichen Projekt und einem öffentlichen Repository
  • Für 60 Minuten auf Microsoft gehosteten Agents mit einem privaten Projekt oder privaten Repository (es sei denn, zusätzliche Kapazität wird bezahlt)

Der Timeoutzeitraum beginnt, wenn der Auftrag ausgeführt wird. Die Zeit, zu der sich der Auftrag in der Warteschlange befindet oder auf einen Agent wartet, ist nicht enthalten.

Ermöglicht timeoutInMinutes das Festlegen eines Grenzwerts für die Ausführungszeit des Auftrags. Wenn nicht angegeben, ist der Standardwert 60 Minuten. Wenn 0 angegeben wird, wird der Höchstwert verwendet (oben beschrieben).

Ermöglicht cancelTimeoutInMinutes es, ein Limit für die Auftragsabbruchzeit festzulegen, wenn der Bereitstellungstask so festgelegt ist, dass er weiterhin ausgeführt wird, wenn ein vorheriger Task fehlgeschlagen ist. Wenn nicht angegeben, ist 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

YAML wird in TFS nicht unterstützt.

Aufträge für Microsoft gehostete Agents haben zusätzliche Einschränkungen, wie lange sie ausgeführt werden können.

Sie können das Timeout für jede Aufgabe auch einzeln festlegen. Weitere Informationen finden Sie unter Aufgabensteuerungsoptionen.

Konfiguration mit mehreren Aufträgen

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

  • Builds mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel erstellen. Sie können beispielsweise eine Visual C++-App für sowohl release als auch debug für Konfigurationen auf und x64x86 plattformen 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.

  • Multikonfigurationstests: Sie können mehrere Konfigurationen parallel testen.

  • Die Mehrfachkonfiguration generiert immer mindestens einen Auftrag, auch wenn eine Variable mit mehreren Konfigurationen leer ist.

Die matrix Strategie ermöglicht es, einen Auftrag mehrmals mit unterschiedlichen Variablensätzen zu versenden. Das maxParallel -Tag schränkt den Umfang der Parallelität ein. Der folgende Auftrag wird dreimal mit den werten Standort und Browser wie angegeben verteilt. Es werden jedoch 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

Matrixkonfigurationsnamen (wie US_IE oben) dürfen nur grundlegende lateinische Alphabetbuchstaben (A-Z, a-z), Zahlen und Unterstriche (_) enthalten. Der Name muss mit einem Buchstaben beginnen. Außerdem müssen sie maximal 100 Zeichen lang sein.

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

matrix akzeptiert einen Laufzeitausdruck, der ein zeichenfolgenifiziertes JSON-Objekt enthält. Dieses JSON-Objekt muss, wenn es erweitert wird, mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel haben wir die JSON-Zeichenfolge hartcodiert, aber sie könnte von einer Skriptsprache oder einem 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

YAML wird in TFS nicht unterstützt.

Aufteilen

Ein Agentauftrag kann verwendet werden, um eine Reihe von Tests parallel auszuführen. Beispielsweise können Sie eine große Suite mit 1.000 Tests auf einem einzelnen Agent ausführen. Alternativ können Sie zwei Agents verwenden und jeweils 500 Tests parallel ausführen.

Um das Schneiden zu nutzen, sollten die Aufgaben im Auftrag intelligent genug sein, um den Slice zu verstehen, zu dem sie gehören.

Der Visual Studio-Testtask ist eine solche Aufgabe, die testslicing unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie der Visual Studio-Testtask auf diesen Agents parallel ausgeführt wird.

Mit parallel der Strategie kann ein Auftrag mehrfach dupliziert werden. Variablen System.JobPositionInPhase und System.TotalJobsInPhase werden jedem Auftrag hinzugefügt. Die Variablen können dann in Ihren Skripts verwendet werden, um die Arbeit auf die Aufträge aufzuteilen. Weitere Informationen finden Sie unter Parallele und mehrfache Ausführung mithilfe von Agentaufträgen.

Der folgende Auftrag wird fünfmal mit den Werten von System.JobPositionInPhaseSystem.TotalJobsInPhase und entsprechend festgelegt.

jobs:
- job: Test
  strategy:
    parallel: 5

YAML wird in TFS nicht unterstützt.

Auftragsvariablen

Wenn Sie YAML verwenden, können Variablen für den Auftrag angegeben werden. Die Variablen können mithilfe der Makrosyntax $(variableName) an Aufgabeneingaben übergeben oder in einem Skript mithilfe der Stufenvariablen zugegriffen werden.

Hier sehen Sie ein Beispiel für das Definieren von Variablen in einem Auftrag und deren Verwendung in Aufgaben.

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"

YAML wird in TFS nicht unterstützt.

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 dem er die Quelle herunterlädt, Schritte ausführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe einer Pipeline.Workspace Variablen verwiesen werden. Dabei werden verschiedene Unterverzeichnisse erstellt:

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich für den Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in dem er die Quelle herunterlädt, Schritte ausführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe einer Agent.BuildDirectory Variablen verwiesen werden. Dabei werden verschiedene Unterverzeichnisse erstellt:

  • Build.SourcesDirectory ist der Ort, an dem Aufgaben den Quellcode der Anwendung herunterladen.
  • Build.ArtifactStagingDirectory ist der Ort, an dem Aufgaben Artefakte herunterladen, die für die Pipeline erforderlich sind, oder Artefakte hochladen, bevor sie veröffentlicht werden.
  • Build.BinariesDirectory ist der Ort, an dem Aufgaben ihre Ausgaben schreiben.
  • Common.TestResultsDirectory ist der Ort, an dem Aufgaben ihre Testergebnisse hochladen.

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

Wenn Sie eine Pipeline auf einem selbstgehosteten Agent ausführen, wird standardmäßig keines der Anderen Unterverzeichnisse als $(Build.ArtifactStagingDirectory) und $(Common.TestResultsDirectory) zwischen zwei aufeinanderfolgenden Ausführungen bereinigt. Daher können Sie inkrementelle Builds und Bereitstellungen durchführen, sofern Aufgaben implementiert werden, um dies zu nutzen. Sie können dieses Verhalten überschreiben, indem Sie die workspace Einstellung für den Auftrag verwenden.

Wichtig

Die Optionen für die Bereinigung des Arbeitsbereichs gelten nur für selbstgehostete Agents. Bei Verwendung Microsoft gehosteter Agents werden Aufträge immer für einen 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 sie wie folgt interpretiert:

  • outputs: Löschen Sie Build.BinariesDirectory , bevor Sie einen neuen Auftrag ausführen.
  • resources: Löschen Sie Build.SourcesDirectory , bevor Sie einen neuen Auftrag ausführen.
  • all: Löschen Sie das gesamte Pipeline.Workspace Verzeichnis, bevor Sie einen neuen Auftrag ausführen.
  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Hinweis

Je nach Ihren Agentfunktionen und Pipelineanforderungen kann jeder Auftrag an einen anderen Agent in Ihrem selbstgehosteten Pool weitergeleitet werden. Daher erhalten Sie möglicherweise einen neuen Agent für nachfolgende Pipelineausführungen (oder Phasen oder Aufträge in derselben Pipeline), sodass die Nichtbereinigung keine Garantie dafür ist, dass nachfolgende Ausführungen, Aufträge oder Phasen auf Ausgaben früherer Ausführungen, Aufträge oder Phasen zugreifen können. Sie können agent-Funktionen und Pipelineanforderungen konfigurieren, um anzugeben, welche Agents zum Ausführen eines Pipelineauftrags verwendet werden. Es gibt jedoch keine Garantie, dass nachfolgende Aufträge denselben Agent wie vorherige Aufträge verwenden, sofern sich nicht nur ein einzelner Agent im Pool befindet, der die Anforderungen erfüllt. Weitere Informationen finden Sie unter Angeben von Anforderungen.

Zusätzlich zur Bereinigung des Arbeitsbereichs können Sie auch die Bereinigung konfigurieren, indem Sie die Einstellung Bereinigen in der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung Bereinigentrue ist, was auch ihr Standardwert ist, entspricht sie der Angabe clean: true für jeden Auscheckschritt in Ihrer Pipeline. Wenn Sie angeben clean: true, werden Sie gefolgt von ausgeführt git clean -ffdx , git reset --hard HEAD bevor Git abgerufen wird. So konfigurieren Sie die Einstellung Bereinigen :

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

    Trigger bearbeiten.

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

    Einstellung

YAML wird in TFS nicht unterstützt.

Artefakt-Download

Diese YAML-Beispieldatei veröffentlicht das Artefakt WebSite und lädt das Artefakt dann in herunter $(Pipeline.Workspace). Der Auftrag Bereitstellen 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: $(System.DefaultWorkingDirectory)

  dependsOn: Build
  condition: succeeded()

YAML wird in TFS nicht unterstützt.

Informationen zur Verwendung von dependsOn und condition finden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können Skripts, die in einem Auftrag ausgeführt werden, 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. Sie muss explizit der Aufgabe oder dem Schritt zugeordnet werden, indem verwendet envwird. Hier siehst du 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)

YAML wird in TFS nicht unterstützt.

Nächste Schritte