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 job
hinzufü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 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:
- Verzögerungsaufgabe
- Aufrufen des Azure-Funktionstasks
- Aufrufen der REST-API-Aufgabe
- Manuelle Überprüfungstask
- Aufgabe "Veröffentlichen in Azure Service Bus"
- Aufgabe "Azure Monitor-Warnungen abfragen"
- Task "Arbeitselemente abfragen"
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 auchdebug
für Konfigurationen auf undx64
x86
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.JobPositionInPhase
System.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 SieBuild.BinariesDirectory
, bevor Sie einen neuen Auftrag ausführen.resources
: Löschen SieBuild.SourcesDirectory
, bevor Sie einen neuen Auftrag ausführen.all
: Löschen Sie das gesamtePipeline.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 :
Bearbeiten Sie Ihre Pipeline, wählen Sie ..., und wählen Sie Trigger aus.
Wählen Sie YAML, Quellen abrufen aus, und konfigurieren Sie die gewünschte Einstellung Bereinigen . Der Standardwert ist true.
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 env
wird.
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.