Angeben von Aufträgen in Ihrer Pipeline

  • Artikel
  • 23 Minuten Lesedauer

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äge 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 in Ihrer YAML-Datei direkt angeben.

Diese YAML-Datei verfügt über einen Auftrag, der auf einem von Microsoft gehostetenHello worldAgent ausgeführt wird und ausgegeben wird.

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 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 verfügt möglicherweise über mehrere Phasen, jeweils mit mehreren Aufträgen. 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 der primäre Zweck Ihres Auftrags darin besteht, Ihre App bereitzustellen (im Gegensatz zum Erstellen oder Testen Ihrer App), können Sie einen speziellen Auftragstyp 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, empfehlen wir, stattdessen einen Bereitstellungsauftrag zu verwenden. Ein Bereitstellungsauftrag hat einige Vorteile. Sie können beispielsweise in einer Umgebung bereitstellen, die Vorteile umfasst, z. B. die Möglichkeit, den Verlauf der bereitgestellten Bereitstellung anzuzeigen.

YAML wird in TFS nicht unterstützt.

Arten von Aufträgen

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 Releasepipelinen verfügbar.
  • Serveraufträge werden auf TFS ausgeführt. Diese Aufträge sind in Build- und Releasepipelinen verfügbar.
  • Bereitstellungsgruppenaufträge werden auf Computern in einer Bereitstellungsgruppe ausgeführt. Diese Aufträge sind nur in Releasepipelinen verfügbar.

Agentpoolaufträge

Dies sind die am häufigsten verwendeten Auftragstypen, und sie werden auf einem Agent in einem Agentpool ausgeführt.

  • Bei der Verwendung von von Microsoft gehosteten Agents erhält jeder Auftrag in einer Pipeline einen neuen Agent.
  • Verwenden Sie Anforderungen mit selbst gehosteten Agents, um anzugeben, welche Funktionen ein Agent zum Ausführen Ihres Auftrags benötigt. Je nachdem, ob mehr als ein Agent in Ihrem Agentpool vorhanden ist, der den Anforderungen Ihrer Pipeline entspricht, erhalten Sie möglicherweise denselben Agent für aufeinander folgende Aufträge. Wenn nur ein Agent in Ihrem Pool 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 selbst gehosteten Agents konzipiert, sodass Aufträge mit einem Agent abgeglichen werden können, der die Anforderungen des Auftrags erfüllt. Wenn Sie microsoft-gehostete Agents verwenden, wählen Sie ein Bild für den Agent aus, der 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 nicht unterstützt.

Weitere Informationen zu Agentfunktionen.

Serveraufträge

Aufgaben in einem Serverauftrag werden von und auf dem Server (Azure Pipelines oder TFS) orchestriert und ausgeführt. Ein Serverauftrag erfordert keinen Agent oder keine Zielcomputer. Derzeit werden nur wenige Aufgaben in einem Serverauftrag unterstützt.

Unterstützte Aufgaben ohne Agent

Derzeit werden nur die folgenden Aufgaben aus dem Feld für agentlose Aufträge unterstützt:

Da Aufgaben erweiterbar sind, können Sie mithilfe von Erweiterungen weitere agentlose Aufgaben hinzufügen. Der Standard-Timeout für agentlose Aufträge 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. Sie benötigen auch ausreichende Parallelaufträ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 fan-out:

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

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 es nicht von einem anderen Auftrag abhängig ist oder ob alle von ihm abgeschlossenen und erfolgreichen Aufträge abhängig sind. Sie können dieses Verhalten anpassen, indem Sie einen Auftrag erzwingen, auch wenn ein vorheriger Auftrag fehlschlägt oder eine benutzerdefinierte Bedingung angibt.

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 in einem vorherigen Auftrag ausgeführt wird. 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 Ressourcen zu vermeiden, wenn Ihr Auftrag nicht mehr reagiert oder zu lange wartet, empfiehlt es sich, ein Limit für die Ausführung Ihres Auftrags festzulegen. Verwenden Sie die Einstellung "Jobtimeout", um den Grenzwert in Minuten für die Ausführung des Auftrags anzugeben. Das Festlegen des Werts auf Null bedeutet, dass der Auftrag ausgeführt werden kann:

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

Der Timeoutzeitraum beginnt, wenn der Auftrag gestartet wird. Es enthält nicht die Zeit, zu der der Auftrag in der Warteschlange steht oder auf einen Agent wartet.

Dies timeoutInMinutes ermöglicht es, für die Auftragsausführungszeit ein Limit festzulegen. Wenn nicht angegeben, beträgt die Standardeinstellung 60 Minuten. Wenn 0 angegeben wird, wird der maximale Grenzwert verwendet (oben beschrieben).

Dies cancelTimeoutInMinutes ermöglicht, dass ein Grenzwert für die Auftragsabbruchzeit festgelegt werden kann, wenn der Bereitstellungsvorgang festgelegt ist, um ausgeführt zu bleiben, wenn eine vorherige Aufgabe fehlgeschlagen ist. Wenn nicht angegeben, ist die Standardeinstellung 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 verfügen über zusätzliche Einschränkungen , wie lange sie ausgeführt werden können.

Sie können auch das Timeout für jeden Vorgang einzeln festlegen – siehe Aufgabensteuerungsoptionen.

Multiauftragskonfiguration

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

  • Multikonfigurationsbuilds: Sie können mehrere Konfigurationen parallel erstellen. Sie können beispielsweise eine Visual C++-App für beide debug und release Konfigurationen auf beiden x86x64 Plattformen erstellen. Weitere Informationen finden Sie unter Visual Studio Build – mehrere Konfigurationen für mehrere Plattformen.

  • Multikonfigurationsbereitstellungen: Sie können mehrere Bereitstellungen parallel ausführen, z. B. zu verschiedenen geografischen Regionen.

  • Multikonfigurationstests: Sie können mehrere Konfigurationen parallel ausführen.

  • Multikonfiguration generiert immer mindestens einen Auftrag, auch wenn eine Multikonfigurationsvariable leer ist.

Mit matrix unterschiedlichen Variablensätzen kann ein Auftrag mehrmals verteilt werden. Das maxParallel Tag beschränkt die Menge an Parallelismus. Der folgende Auftrag wird dreimal mit den Werten "Standort" und "Browser" wie angegeben verteilt. Allerdings werden 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) müssen nur grundlegende lateinische Alphabetbuchstaben (A-Z, a-z), Zahlen und Unterstriche_ () enthalten. Der Name muss mit einem Buchstaben beginnen. Außerdem müssen sie 100 Zeichen oder weniger sein.

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

matrix akzeptiert einen Laufzeitausdruck mit einem Zeichenfolgen-JSON-Objekt. Dieses JSON-Objekt, wenn erweitert, muss mit der Matrixsyntax übereinstimmen. Im folgenden Beispiel haben wir die JSON-Zeichenfolge hart codiert, aber es 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. Sie können beispielsweise eine große Suite von 1000 Tests auf einem einzelnen Agent ausführen. Sie können auch zwei Agents verwenden und 500 Tests gleichzeitig ausführen.

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

Die Visual Studio-Testaufgabe ist eine solche Aufgabe, die Test-Slicing unterstützt. Wenn Sie mehrere Agents installiert haben, können Sie angeben, wie die Visual Studio-Testaufgabe parallel auf diesen Agents ausgeführt wird.

Mit der parallel Strategie kann ein Auftrag mehrmals 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 zwischen den Aufträgen zu teilen. Siehe Parallele und mehrere Ausführung mit Agentaufträgen.

Der folgende Auftrag wird fünf Mal mit den Werten System.JobPositionInPhase von und System.TotalJobsInPhase festgelegt, die entsprechend festgelegt werden.

jobs:
- job: Test
  strategy:
    parallel: 5

YAML wird in TFS nicht unterstützt.

Auftragsvariablen

Wenn Sie YAML verwenden, können Variablen im Auftrag angegeben werden. Die Variablen können mithilfe der Makrosyntax $(variableName) an Aufgabeneingaben übergeben oder mithilfe der Phasenvariablen innerhalb eines Skripts aufgegriffen werden.

Hier sehen Sie ein Beispiel für die Definition von Variablen in einem Auftrag und verwenden sie innerhalb von Vorgängen.

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, erstellt er einen Arbeitsbereich im Agent. Der Arbeitsbereich ist ein Verzeichnis, in dem er die Quelle herunterlädt, Schritte ausführt und Ausgabe erzeugt. Das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe Pipeline.Workspace einer Variablen referenziert werden. Unter diesem Thema werden verschiedene Unterverzeichnisse erstellt:

Wenn Sie einen Agentpoolauftrag ausführen, erstellt er einen Arbeitsbereich im Agent. Der Arbeitsbereich ist ein Verzeichnis, in dem er die Quelle herunterlädt, Schritte ausführt und Ausgabe erzeugt. Das Arbeitsbereichsverzeichnis kann in Ihrem Auftrag mithilfe Agent.BuildDirectory einer Variablen referenziert werden. Unter diesem Thema werden verschiedene Unterverzeichnisse erstellt:

  • Build.SourcesDirectory Hier laden Aufgaben den Quellcode der Anwendung herunter.
  • Build.ArtifactStagingDirectory Hier laden Aufgaben Artefakte herunter, die für die Pipeline benötigt werden oder Artefakte hochladen, bevor sie veröffentlicht werden.
  • Build.BinariesDirectory Hier schreiben Aufgaben ihre Ausgabe.
  • Common.TestResultsDirectory Hier laden Aufgaben ihre Testergebnisse hoch.

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

Wenn Sie eine Pipeline auf einem selbst gehosteten Agent ausführen, werden standardmäßig keine unterverzeichnisse als $(Build.ArtifactStagingDirectory)$(Common.TestResultsDirectory) zwischen zwei aufeinander folgenden Ausführungen bereinigt. Daher können Sie inkrementelle Builds und Bereitstellungen ausführen, sofern Aufgaben implementiert werden, um dies zu nutzen. Sie können dieses Verhalten überschreiben, indem Sie die workspace Einstellung im Auftrag verwenden.

Wichtig

Die Arbeitsbereichreinigungsoptionen gelten nur für selbst gehostete Agents. Wenn Sie Microsoft gehostete Agents verwenden, werden 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 clean Optionen angeben, werden sie wie folgt interpretiert:

  • outputs: Löschen Build.BinariesDirectory vor dem Ausführen eines neuen Auftrags.
  • resources: Löschen Build.SourcesDirectory vor dem Ausführen eines neuen Auftrags.
  • 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

Abhängig von Ihren Agentfunktionen und Pipelineanforderungen kann jeder Auftrag an einen anderen Agent in Ihrem selbst gehosteten 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 keine Reinigung gewährleistet ist, dass nachfolgende Ausführungen, Aufträge oder Phasen auf Ausgaben aus früheren Ausführungen, 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 sei denn, es gibt nur einen einzelnen Agent im Pool, der die Anforderungen erfüllt, es gibt keine Garantie, dass nachfolgende Aufträge denselben Agent wie frühere Aufträge verwenden. Weitere Informationen finden Sie unter Angeben von Anforderungen.

Zusätzlich zur Arbeitsbereichreinigung können Sie auch die Reinigung konfigurieren, indem Sie die Einstellung " Bereinigen" in der Benutzeroberfläche der Pipelineeinstellungen konfigurieren. Wenn die Einstellung "Bereinigen " wahr ist, entspricht es der Angabe clean: true für jeden Auscheckschritt in Ihrer Pipeline. Wenn Sie angebenclean: true, werden Sie gefolgt, git reset --hard HEAD bevor Git-Abruf ausgeführt git clean -ffdx wird. So konfigurieren Sie die Einstellung "Bereinigen ":

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

    Bearbeitungsauslöser.

  2. Wählen Sie YAML, Quellen abrufen und Ihre gewünschte Einstellung "Sauber " konfigurieren. Die Standardeinstellung ist false.

    Bereinigungseinstellung.

YAML wird in TFS nicht unterstützt.

Artefakte-Download

In dieser Beispiel-YAML-Datei wird das Artefakte veröffentlicht und dann das Artefakte WebSite heruntergeladen $(Pipeline.Workspace). 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 nicht unterstützt.

Informationen zur Verwendung von Abhängigkeit und Bedingung finden Sie unter Angeben von Bedingungen.

Zugriff auf OAuth-Token

Sie können Skripts zulassen, die in einem Auftrag ausgeführt werden, um auf das aktuelle Azure-Pipelines- oder TFS OAuth-Sicherheitstoken zuzugreifen. Das Token kann zum Authentifizieren der REST-API von Azure Pipelines verwendet werden.

Das OAuth-Token ist immer für YAML-Pipelines verfügbar. Es muss explizit dem Vorgang oder Schritt zugeordnet werden, indem enver verwendet wird. Hier sehen Sie 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