Aufgabentypen -verwendung

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.

Eine Aufgabe ist der Baustein zum Definieren der Automatisierung in einer Pipeline. Eine Aufgabe ist einfach ein verpacktes Skript oder eine Prozedur, die mit einer Reihe von Eingaben abstrahiert wurde.

Wenn Sie Ihrer Pipeline eine Aufgabe hinzufügen, kann sie auch eine Reihe von Anforderungen an die Pipeline hinzufügen. Die Anforderungen definieren die Voraussetzungen, die auf dem Agent installiert werden müssen, damit die Aufgabe ausgeführt werden kann. Wenn Sie den Build oder die Bereitstellung ausführen, wird ein Agent ausgewählt, der diese Anforderungen erfüllt.

Wenn Sie einen Auftrag ausführen, werden alle Aufgaben in Sequenz ausgeführt, eine nach der anderen. Informationen zum Ausführen derselben Aufgabengruppen parallel auf mehreren Agents oder zum Ausführen einiger Aufgaben ohne Verwendung eines Agents finden Sie unter Aufträge.

Standardmäßig werden alle Aufgaben im gleichen Kontext ausgeführt, unabhängig davon, ob sie sich auf dem Host oder in einem Auftragscontainer befinden. Sie können optional Schrittziele verwenden, um den Kontext für einen einzelnen Vorgang zu steuern.

Erfahren Sie mehr darüber, wie Sie Eigenschaften für einen Vorgang mit den integrierten Vorgängen angeben.

Wenn Sie einen Auftrag ausführen, werden alle Aufgaben nacheinander auf einem Agent ausgeführt. Informationen zum Ausführen derselben Aufgabengruppen parallel auf mehreren Agents oder zum Ausführen einiger Aufgaben ohne Verwendung eines Agents finden Sie unter Aufträge.

Benutzerdefinierte Aufgaben

Wir stellen einige integrierte Aufgaben bereit, um grundlegende Build- und Bereitstellungsszenarien zu ermöglichen. Wir haben auch Anleitungen zum Erstellen Ihrer eigenen benutzerdefinierten Aufgabe bereitgestellt.

Darüber hinaus bietet Visual Studio Marketplace eine Reihe von Erweiterungen; jede, wenn sie in Ihrem Abonnement oder Ihrer Sammlung installiert ist, erweitert den Aufgabenkatalog mit mindestens einer Aufgabe. Darüber hinaus können Sie eigene benutzerdefinierte Erweiterungen schreiben, um Aufgaben zu Azure Pipelines oder TFS hinzuzufügen.

In YAML-Pipelines verweisen Sie nach Namen auf Vorgänge. Wenn ein Name sowohl mit einem In-Box-Vorgang als auch mit einem benutzerdefinierten Vorgang übereinstimmt, hat der Feldvorgang Vorrang. Sie können die Aufgaben-GUID oder einen vollqualifizierten Namen für den benutzerdefinierten Vorgang verwenden, um dieses Risiko zu vermeiden:

steps:
- task: myPublisherId.myExtensionId.myContributionId.myTaskName@1 #format example
- task: qetza.replacetokens.replacetokens-task.replacetokens@3 #working example

Um eine Aufgabe auf dem Marketplace zu suchen myPublisherId und myExtensionIdauszuwählen, wählen Sie " Abrufen " aus. Die Werte nach der itemName URL-Zeichenfolge sind myPublisherId und myExtensionId. Sie können auch den vollqualifizierten Namen finden, indem Sie die Aufgabe zu einer Releasepipeline hinzufügen und yaML anzeigen, wenn Sie die Aufgabe bearbeiten.

Aufgabenversionen

Aufgaben sind versioniert, und Sie müssen die Hauptversion des Vorgangs angeben, der in Ihrer Pipeline verwendet wird. Dies kann dazu beitragen, Probleme zu verhindern, wenn neue Versionen einer Aufgabe freigegeben werden. Aufgaben sind in der Regel abwärtskompatibel, in einigen Szenarien treten jedoch möglicherweise unvorhersehbare Fehler auf, wenn eine Aufgabe automatisch aktualisiert wird.

Wenn eine neue Nebenversion veröffentlicht wird (z. B. 1.2 bis 1.3), verwendet Ihr Build oder Ihre Version automatisch die neue Version. Wenn jedoch eine neue Hauptversion veröffentlicht wird (z. B. 2.0), verwendet Ihr Build oder Ihre Version weiterhin die von Ihnen angegebene Hauptversion, bis Sie die Pipeline bearbeiten und manuell in die neue Hauptversion wechseln. Das Build- oder Releaseprotokoll enthält eine Warnung, dass eine neue Hauptversion verfügbar ist.

Sie können festlegen, welche Nebenversion verwendet wird, indem Sie die Vollständige Versionsnummer einer Aufgabe nach dem @ Signieren angeben (Beispiel: GoTool@0.3.1). Sie können nur Aufgabenversionen verwenden, die für Ihre Organisation vorhanden sind.

In YAML geben Sie die Hauptversion im @ Aufgabennamen an. Um beispielsweise an Version 2 der PublishTestResults Aufgabe anzuheften:

steps:
- task: PublishTestResults@2

YAML-Pipelines sind in TFS nicht verfügbar.

Aufgabensteuerungsoptionen

Jeder Vorgang bietet Ihnen einige Steuerelementoptionen.

Steuerelementoptionen sind als Tasten im task Abschnitt verfügbar.

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task

Steuerelementoptionen sind als Tasten im task Abschnitt verfügbar.

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Steuerelementoptionen sind als Tasten im task Abschnitt verfügbar.

- task: string  # reference to a task and version, e.g. "VSBuild@1"
  condition: expression     # see below
  continueOnError: boolean  # 'true' if future steps should run even if this step fails; defaults to 'false'
  enabled: boolean          # whether or not to run this step; defaults to 'true'
  retryCountOnTaskFailure: number # Max number of retries; default is zero
  timeoutInMinutes: number  # how long to wait before timing out the task
  target: string            # 'host' or the name of a container resource to target

Hinweis

Eine bestimmte Aufgabe oder ein Auftrag kann nicht einseitig entscheiden, ob der Auftrag/die Phase fortgesetzt wird. Was es tun kann, ist ein Status von erfolgreich oder fehlgeschlagen, und nachgelagerte Aufgaben/Aufträge verfügen jeweils über eine Bedingungsberechnung, mit der sie entscheiden können, ob sie ausgeführt werden sollen oder nicht. Die Standardbedingung, die effektiv "ausgeführt wird, wenn wir in einem erfolgreichen Zustand sind".

Fahren Sie mit Fehlerfehlern fort, um dies auf subtile Weise zu ändern. Es "trickst" effektiv alle nachgelagerten Schritte/Aufträge, um jedes Ergebnis als "Erfolg" zu behandeln, um diese Entscheidung zu treffen. Oder um es auf eine andere Weise zu platzieren, sagt es", "denken Sie nicht an den Fehler dieser Aufgabe, wenn Sie eine Entscheidung über die Bedingung der enthaltenden Struktur treffen".

Der Timeoutzeitraum beginnt, wenn die Aufgabe ausgeführt wird. Es enthält nicht die Zeit, zu der die Aufgabe in die Warteschlange gestellt wird oder auf einen Agent wartet.

In diesem YAML wird auch ausgeführt, PublishTestResults@2 wenn der vorherige Schritt aufgrund der erfolgreichen BedingungOrFailed() fehlschlägt.

steps:
- task: UsePythonVersion@0
  inputs:
    versionSpec: '3.7'
    architecture: 'x64'
- task: PublishTestResults@2
  inputs:
    testResultsFiles: "**/TEST-*.xml"
  condition: succeededOrFailed()

Bedingungen

  • Nur wenn alle vorherigen direkten und indirekten Abhängigkeiten mit demselben Agentpool erfolgreich sind. Wenn Sie über verschiedene Agentpools verfügen, werden diese Phasen oder Aufträge gleichzeitig ausgeführt. Dies ist die Standardeinstellung, wenn keine Bedingung im YAML festgelegt ist.

  • Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, außer wenn die Ausführung abgebrochen wurde. Verwenden Sie succeededOrFailed() in yaML für diese Bedingung.

  • Auch wenn eine vorherige Abhängigkeit fehlgeschlagen ist, auch wenn die Ausführung abgebrochen wurde. Verwenden Sie always() in yaML für diese Bedingung.

  • Nur wenn eine vorherige Abhängigkeit fehlgeschlagen ist. Verwenden Sie failed() in yaML für diese Bedingung.

Schrittziel

Aufgaben werden in einem Ausführungskontext ausgeführt, der entweder der Agenthost oder ein Container ist. Ein einzelner Schritt kann seinen Kontext überschreiben, indem er eine target. Verfügbare Optionen sind das Wort host , um auf den Agenthost und alle container zu abzielen, die in der Pipeline definiert sind. Zum Beispiel:

resources:
  containers:
  - container: pycontainer
    image: python:3.8

steps:
- task: SampleTask@1
  target: host
- task: AnotherTask@1
  target: pycontainer

Hier wird der SampleTask Host ausgeführt und AnotherTask in einem Container ausgeführt.

Anzahl der Wiederholungen, wenn der Vorgang fehlgeschlagen ist

Geben Sie retryCountOnTaskFailure die Anzahl der Wiederholungen an, wenn der Vorgang fehlschlägt. Der Standardwert ist 0.

- task: <name of task>
   retryCountOnTaskFailure: <max number of retries>
   ...

Hinweis

  • Erfordert Agent Version 2.194.0 oder höher. Wird für agentlose Aufgaben nicht unterstützt.
  • Der fehlerhafte Vorgang wird sofort erneut ausgeführt.
  • Es gibt keine Annahme über die Idempotenz der Aufgabe. Wenn der Vorgang Nebenwirkungen hat (z. B. wenn er eine externe Ressource teilweise erstellt hat), schlägt er möglicherweise das zweite Mal fehl, wenn er ausgeführt wird.
  • Es gibt keine Informationen zur Wiederholungsanzahl, die der Aufgabe zur Verfügung gestellt wurde.
  • Eine Warnung wird den Aufgabenprotokollen hinzugefügt, die angibt, dass sie fehlgeschlagen ist, bevor sie erneut ausgeführt wird.
  • Alle Versuche, eine Aufgabe erneut auszuführen, werden in der Benutzeroberfläche als Teil desselben Aufgabenknotens angezeigt.

YAML-Pipelines sind in TFS nicht verfügbar.

Umgebungsvariablen

YAML-Pipelines werden in Azure DevOps Server 2019 und höher unterstützt.

Jede Aufgabe verfügt über eine env Eigenschaft, die eine Liste von Zeichenfolgenpaaren ist, die Umgebungsvariablen darstellen, die dem Vorgangsprozess zugeordnet sind.

task: AzureCLI@2
displayName: Azure CLI
inputs: # Specific to each task
env:
  ENV_VARIABLE_NAME: value
  ENV_VARIABLE_NAME2: value
  ...

Im folgenden Beispiel wird der script Schritt ausgeführt, der eine Verknüpfung für die Befehlszeilenaufgabe ist, gefolgt von der entsprechenden Aufgabensyntax. In diesem Beispiel wird der AZURE_DEVOPS_EXT_PAT Umgebungsvariable ein Wert zugewiesen, der zum Authentifizieren mit Azure DevOps CLI verwendet wird.

# Using the script shortcut syntax
- script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the script step'

# Using the task syntax
- task: CmdLine@2
  inputs:
    script: az pipelines variable-group list --output table
  env:
    AZURE_DEVOPS_EXT_PAT: $(System.AccessToken)
  displayName: 'List variable groups using the command line task'

Buildtoolinstallationsprogramme (Azure Pipelines)

Toolinstallationsprogramme ermöglichen es Ihrer Buildpipeline, Ihre Abhängigkeiten zu installieren und zu steuern. Sie haben insbesondere folgende Möglichkeiten:

Sie können beispielsweise Ihre Buildpipeline einrichten, um Ihre App für mehrere Versionen von Node.js auszuführen und zu überprüfen.

Beispiel: Testen und Überprüfen Der App auf mehreren Versionen von Node.js

Erstellen Sie eine Azure-pipelines.yml-Datei im Basisverzeichnis Ihres Projekts mit den folgenden Inhalten.

pool:
  vmImage: 'Ubuntu 16.04'

steps:
# Node install
- task: NodeTool@0
  displayName: Node install
  inputs:
    versionSpec: '6.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Erstellen Sie eine neue Buildpipeline , und führen Sie sie aus. Beobachten Sie, wie der Build ausgeführt wird. Der Node.js Tool Installer lädt die Node.js Version herunter, wenn sie nicht bereits auf dem Agent vorhanden ist. Das Befehlszeilenskript protokolliert den Speicherort der Node.js Version auf dem Datenträger.

YAML-Pipelines sind in TFS nicht verfügbar.

Aufgaben des Toolinstallationsprogramms

Eine Liste unserer Toolinstallationsaufgaben finden Sie unter Tool-Installationsaufgaben.

Deaktivieren von In-Box- und Marketplace-Aufgaben

Auf der Seite "Organisationseinstellungen" können Sie Marketplace-Aufgaben, Boxaufgaben oder beides deaktivieren. Das Deaktivieren von Marketplace-Aufgaben kann dazu beitragen, die Sicherheit Ihrer Pipelines zu erhöhen . Wenn Sie sowohl box- als auch Marketplace-Aufgaben deaktivieren, sind nur Aufgaben verfügbar, die Sie installieren tfx .

Hilfe und Support