Angeben von Aufträgen in Ihrer Pipeline

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 | TFS 2017

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. Anders ausgedrückt: Ein Auftrag ist die kleinste Arbeitseinheit, für die 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. Anders ausgedrückt: Ein Auftrag ist die kleinste Arbeitseinheit, für die 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.

Sie können Ihre Releasepipeline in Aufträgen organisieren. Jede Releasepipeline verfügt über mindestens einen Auftrag. Aufträge werden in dieser TFS-Version in einer Buildpipeline nicht unterstützt.

Hinweis

Sie müssen Update 2 installieren, um Aufträge in einer Releasepipeline in TFS 2017 zu verwenden. Aufträge in Buildpipelines sind in Azure Pipelines, TFS 2018.2 und neueren Versionen verfügbar.

Definieren eines einzelnen Auftrags

Im einfachsten Fall verfügt eine Pipeline über einen einzelnen Auftrag. In diesem Fall müssen Sie das Schlüsselwort nur explizit verwenden, job wenn Sie eine jobverwenden. Sie können die Schritte in Ihrer YAML-Datei direkt angeben.

Diese YAML-Datei verfügt über einen Auftrag, der auf einem von Microsoft gehosteten Agent ausgeführt wird und ausgibt.

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

Möglicherweise möchten Sie 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 kann mehrere Aufträge aufweisen. 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 (im Gegensatz zum Erstellen oder Testen Ihrer App), können Sie einen speziellen Auftragstyp namens Bereitstellungsauftragverwenden.

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 hinzufügen job können, wird empfohlen, stattdessen einen jobzu 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 dieser Version von TFS nicht unterstützt.

Typen von Aufträgen

Aufträge können je nach Ausführungsort unterschiedliche Typen aufweisen.

  • Agentpoolaufträge werden auf einem Agent in einem Agentpool ausgeführt.
  • Serveraufträge werden auf dem Azure DevOps Server 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 auf dem Azure DevOps Server 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 auf 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 werden auf einem Agent im Agentpool ausgeführt. Diese Aufträge sind nur verfügbare Releasepipelines.

Agentpoolaufträge

Dies sind die gängigsten Typen von Aufträgen, die auf einem Agent in einem Agentpool ausgeführt werden.

  • Bei Verwendung von von Microsoft gehosteten 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 Des Auftrags benötigen muss. Sie erhalten möglicherweise den gleichen Agent für aufeinanderfolgende Aufträge, je nachdem, ob in Ihrem Agentpool mehrere Agents vorhanden sind, die den Anforderungen Ihrer Pipeline entsprechen. Wenn nur ein Agent in Ihrem Pool 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 abgegleichen 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 keine Funktionen mit von 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 noch nicht unterstützt.

Erfahren Sie mehr über agent-Funktionen.

Serveraufträge

Aufgaben in einem Serverauftrag werden von orchestriert und auf dem Server ausgeführt (Azure Pipelines oder TFS). Für einen Serverauftrag sind weder ein Agent noch Zielcomputer erforderlich. Derzeit werden nur wenige Aufgaben in einem Serverauftrag unterstützt.

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

Derzeit werden nur die folgenden Tasks sofort 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

Sie können auch die vereinfachte Syntax verwenden:

jobs:
- job: string
  pool: server

YAML wird in TFS noch nicht unterstützt.

Abhängigkeiten

Wenn Sie mehrere Aufträge in einer einzelnen Phase definieren, können Sie Abhängigkeiten zwischen ihnen angeben. Pipelines muss 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 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-Builds sind in TFS noch nicht verfügbar.

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 waren. Sie können dieses Verhalten anpassen, indem Sie erzwingen, dass ein Auftrag ausgeführt wird, auch 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-Builds sind in TFS noch nicht verfügbar.

Timeouts

Um das Aufnehmen von Ressourcen zu vermeiden, wenn Ihr Auftrag nicht reagiert oder zu lange wartet, empfiehlt es sich, einen Grenzwert für die Ausführung ihres Auftrags festzulegen. 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 (null) bedeutet, dass der Auftrag ausgeführt werden kann:

  • Forever für selbstgehostete Agents
  • 360 Minuten (6 Stunden) auf von Microsoft gehosteten Agents mit einem öffentlichen Projekt und einem öffentlichen Repository
  • 60 Minuten lang auf von Microsoft gehosteten Agents mit einem privaten Projekt oder privaten Repository (sofern keine zusätzliche Kapazität bezahlt wird)

Der Timeoutzeitraum beginnt, wenn der Auftrag gestartet wird. Die Zeit, in der der Auftrag in die Warteschlange eingereiht wird oder auf einen Agent wartet, ist nicht enthalten.

timeoutInMinutesErmöglicht das Festlegen eines Grenzwerts für die Ausführungszeit des Auftrags. Wenn keine Angabe erfolgt, beträgt der Standardwert 60 Minuten. Wenn 0 angegeben wird, wird der maximale Grenzwert verwendet (oben beschrieben).

cancelTimeoutInMinutesErmöglicht das Festlegen eines Grenzwerts für die Abbruchzeit des Auftrags, wenn der Bereitstellungstask so festgelegt ist, dass er weiterhin ausgeführt wird, wenn ein vorheriger Task fehlgeschlagen ist. Wenn keine Angabe erfolgt, beträgt der Standardwert 5 Minuten. Der Wert sollte zwischen 1 und 35.790 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 noch nicht unterstützt.

Für Aufträge, die auf von Microsoft gehostete Agents ausgerichtet sind, gelten zusätzliche Einschränkungen hinsichtlich der Dauer ihrer Ausführung.

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

Konfiguration mehrerer Aufgaben

Über einen einzelnen Auftrag, den Sie erstellen, können Sie mehrere Aufträge auf mehreren Agents parallel ausführen. Beispiele:

  • Builds mit mehreren Konfigurationen: Sie können mehrere Konfigurationen parallel erstellen. Sie können z. B. eine Visual C++-App sowohl für - als auch für debugrelease -Konfigurationen auf - und x86 -Plattformen 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 der Mehrfachkonfiguration wird immer mindestens ein Auftrag generiert, 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 die Parallelität ein. Der folgende Auftrag wird dreimal mit den werten Location und Browser wie angegeben versendet. 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 oben) dürfen nur grundlegende lateinische Buchstaben US_IE (A-Z, a-z), Zahlen und Unterstriche ( ) _ enthalten. Sie müssen mit einem Buchstaben beginnen. Außerdem müssen sie mindestens 100 Zeichen lang sein.

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

matrix akzeptiert einen Laufzeitausdruck, der ein Zeichenfolgen-JSON-Objekt enthält. Dieses JSON-Objekt muss, wenn es erweitert ist, mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel haben wir die JSON-Zeichenfolge hart codiert, aber sie kann 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 durchzuführen. Beispielsweise können Sie eine große Suite von 1.000 Tests auf einem einzelnen Agent ausführen. Oder Sie können zwei Agents verwenden und 500 Tests parallel für jeden ausführen.

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

Der Visual Studio Test-Task ist eine dieser Aufgaben, die Testslicing unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie der Visual Studio Test-Task auf diesen Agents parallel ausgeführt wird.

Die parallel Strategie ermöglicht das mehrfache Duplizieren eines Auftrags. 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 zu unterteilen. Weitere Informationen finden Sie unter Parallele und mehrfache Ausführung mitHilfe von Agentaufträgen.

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

jobs:
- job: Test
  strategy:
    parallel: 5

YAML wird in TFS noch 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 innerhalb eines Skripts mithilfe der Stufenvariablen aufgerufen werden.

Im Folgenden finden Sie ein Beispiel für das Definieren von Variablen in einem Auftrag und deren Verwendung innerhalb von 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 noch nicht unterstützt.

Informationen zur Verwendung einer Bedingung finden Sie unterAngeben von Bedingungen.

Arbeitsbereich

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich auf dem Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in das er die Quelle herunterlädt, Schritte ausgeführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe der Variablen verwiesen Pipeline.Workspace werden. Unter diesem werden verschiedene Unterverzeichnisse erstellt:

Wenn Sie einen Agentpoolauftrag ausführen, wird ein Arbeitsbereich auf dem Agent erstellt. Der Arbeitsbereich ist ein Verzeichnis, in das er die Quelle herunterlädt, Schritte ausgeführt und Ausgaben erzeugt. Auf das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe der Variablen verwiesen Agent.BuildDirectory werden. Unter diesem 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 benötigt werden, oder Artefakte hochladen, bevor sie veröffentlicht werden.
  • Build.BinariesDirectory ist der Ort, an dem Tasks ihre Ausgaben schreiben.
  • Common.TestResultsDirectory ist der Ort, an dem Tasks ihre Testergebnisse hochladen.

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

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

Wichtig

Die Bereinigungsoptionen für Arbeitsbereiche gelten nur für selbstge gehostete Agents. Wenn Sie von Microsoft gehostete Agents verwenden, wird der Auftrag 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 Optionen clean angeben, werden sie wie folgt interpretiert:

  • outputs: Löschen Build.BinariesDirectory Sie , bevor Sie einen neuen Auftrag ausführen.
  • resources: Löschen Build.SourcesDirectory Sie , 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: deploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Hinweis

Je nach Agent-Funktionen und Pipelineanforderungen kann jeder Auftrag an einen anderen Agent in Ihrem selbstge gehosteten Pool geroutet werden. Daher erhalten Sie möglicherweise einen neuen Agent für nachfolgende Pipelineläufe (oder Phasen oder Aufträge in derselben Pipeline). Daher ist keine Bereinigung eine Garantie dafür, dass nachfolgende Läufe, Aufträge oder Phasen auf Ausgaben von vorherigen Läufen, Aufträgen oder Phasen zugreifen können. Sie können Agentfunktionen und Pipelineanforderungen konfigurieren, um anzugeben, welche Agents zum Ausführen eines Pipelineauftrags verwendet werden. Es ist jedoch nicht garantiert, dass nachfolgende Aufträge denselben Agent wie vorherige Aufträge verwenden, es sei denn, es gibt nur einen einzelnen Agent im Pool, der die Anforderungen erfüllt. Weitere Informationen finden Sie unter Angeben von Anforderungen.

Zusätzlich zur Arbeitsbereichsbereinigung können Sie auch die Bereinigung konfigurieren, indem Sie die Einstellung Bereinigen auf der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung Bereinigenauf TRUE festgelegt ist, entspricht dies der Angabe für jeden Auscheckschritt in Ihrer Pipeline. 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, Quellen abrufenaus, und konfigurieren Sie die gewünschte Einstellung Bereinigen. Der Standardwert ist FALSE.

    Bereinigungseinstellung.

YAML wird in TFS noch nicht unterstützt.

Artefaktdownload

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

  dependsOn: Build
  condition: succeeded()

YAML wird in TFS noch nicht unterstützt.

Informationen zur Verwendung von dependsOn und bedingungfinden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können skripts, die in einem Auftrag ausgeführt werden, den Zugriff auf das aktuelle Azure Pipelines oder TFS-OAuth-Sicherheitstoken gestatten. Das Token kann für die Authentifizierung bei der Azure Pipelines REST-API verwendet werden.

Das OAuth-Token ist immer für YAML-Pipelines verfügbar. Sie muss der Aufgabe oder dem Schritt mit explizit zugeordnet env 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)

YAML wird in TFS noch nicht unterstützt.

Ausblick