Typy zadań i użycie

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

Uwaga

Program Microsoft Visual Studio Team Foundation Server 2018 i starsze wersje mają następujące różnice w nazewnictwie:

  • Potoki kompilacji i wydania są nazywane definicjami
  • Uruchomienia są nazywane kompilacjami
  • Połączenia usługi są nazywane punktami końcowymi usługi
  • Etapy są nazywane środowiskami
  • Zadania są nazywane fazami

Zadanie wykonuje akcję w potoku i jest spakowanym skryptem lub procedurą abstrakcyjną z zestawem danych wejściowych. Zadania to bloki konstrukcyjne służące do definiowania automatyzacji w potoku.

Dodanie zadania do potoku może również spowodować dodanie zestawu wymagań do potoku. Wymagania definiują wymagania wstępne, które muszą być zainstalowane na agencie , aby zadanie było uruchamiane. Po uruchomieniu kompilacji lub wdrożenia wybierany jest agent spełniający te wymagania.

Po uruchomieniu zadania wszystkie zadania są uruchamiane w sekwencji, jeden po drugim. Aby uruchomić ten sam zestaw zadań równolegle na wielu agentach lub uruchomić niektóre zadania bez użycia agenta, zobacz zadania.

Domyślnie wszystkie zadania są uruchamiane w tym samym kontekście, zarówno na hoście, jak i w kontenerze zadań.

Opcjonalnie możesz użyć elementów docelowych kroków, aby kontrolować kontekst pojedynczego zadania.

Dowiedz się więcej o sposobie określania właściwości zadania za pomocą wbudowanych zadań.

Po uruchomieniu zadania wszystkie zadania są uruchamiane w sekwencji, jeden po drugim, na agencie. Aby uruchomić ten sam zestaw zadań równolegle na wielu agentach lub uruchomić niektóre zadania bez użycia agenta, zobacz zadania.

Aby dowiedzieć się więcej na temat ogólnych atrybutów obsługiwanych przez zadania, zobacz dokumentację YAML dotyczącą kroków.task.

Zadania niestandardowe

Usługa Azure DevOps obejmuje wbudowane zadania umożliwiające podstawowe scenariusze kompilacji i wdrażania. Możesz również utworzyć własne zadanie niestandardowe.

Ponadto witryna Visual Studio Marketplace oferuje wiele rozszerzeń, z których każdy po zainstalowaniu w subskrypcji lub kolekcji rozszerza katalog zadań o co najmniej jedno zadanie. Możesz również napisać własne rozszerzenia niestandardowe, aby dodać zadania do usługi Azure Pipelines.

W potokach YAML odwołujesz się do zadań według nazwy. Jeśli nazwa pasuje zarówno do zadania w polu, jak i zadania niestandardowego, zadanie w polu ma pierwszeństwo. Aby uniknąć tego ryzyka, możesz użyć identyfikatora GUID zadania lub w pełni kwalifikowanej nazwy zadania niestandardowego:

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

Aby znaleźć myPublisherId i myExtensionId, wybierz pozycję Pobierz w zadaniu w witrynie Marketplace. Wartości po itemName ciągu adresu URL to myPublisherId i myExtensionId. Możesz również znaleźć w pełni kwalifikowaną nazwę, dodając zadanie do potoku wydania i wybierając pozycję Wyświetl KOD YAML podczas edytowania zadania.

Wersje zadań

Zadania są wersjonowane i należy określić wersję główną zadania używanego w potoku. Może to pomóc w zapobieganiu problemom w przypadku wydania nowych wersji zadania. Zadania są zwykle zgodne z poprzednimi wersjami, ale w niektórych scenariuszach mogą wystąpić nieprzewidywalne błędy, gdy zadanie zostanie automatycznie zaktualizowane.

Po wydaniu nowej wersji pomocniczej (na przykład od 1.2 do 1.3) potok automatycznie używa nowej wersji. Jeśli jednak zostanie wydana nowa wersja główna (na przykład 2.0), potok będzie nadal używać określonej wersji głównej, dopóki potok nie zostanie edytowany i ręcznie zmieni się na nową wersję główną. Dziennik będzie zawierać alert, że jest dostępna nowa wersja główna.

Możesz ustawić, która wersja pomocnicza jest używana, określając pełny numer wersji zadania po @ znaku (na przykład: GoTool@0.3.1). W organizacji można używać tylko wersji zadań, które istnieją.

W języku YAML należy określić wersję główną używaną @ w nazwie zadania. Aby na przykład przypiąć do wersji 2 PublishTestResults zadania:

steps:
- task: PublishTestResults@2

Potoki YAML nie są dostępne w programie TFS.

Opcje sterowania zadania

Każde zadanie oferuje niektóre opcje sterowania.

Opcje sterowania są dostępne jako klucze w task sekcji.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.

Opcje sterowania są dostępne jako klucze w task sekcji.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Opcje sterowania są dostępne jako klucze w task sekcji.

- task: string # Required as first property. Name of the task to run.
  inputs: # Inputs for the task.
    string: string # Name/value pairs
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Uwaga

Danego zadania lub zadania nie można jednostronnie zdecydować, czy zadanie/etap jest kontynuowane. To, co może zrobić, to zaoferować stan powodzenia lub niepowodzenia, a podrzędne zadania/zadania mają obliczenia warunku, które pozwalają im zdecydować, czy uruchomić, czy nie. Warunek domyślny, który jest skutecznie "uruchamiany, jeśli jesteśmy w stanie powodzenia".

Kontynuuj na błędzie zmienia to w subtelny sposób. Skutecznie "sztuczki" wszystkie kroki podrzędne/zadania do traktowania dowolnego wyniku jako "sukcesu" na potrzeby podejmowania tej decyzji. Albo ująć to w inny sposób, mówi: "Nie należy brać pod uwagę niepowodzenia tego zadania, gdy podejmujesz decyzję o stanie zawierającej strukturę".

Okres przekroczenia limitu czasu rozpoczyna się po uruchomieniu zadania. Nie uwzględnia czasu kolejki zadania lub oczekiwania na agenta.

Uwaga

Potoki mogą mieć limit czasu na poziomie zadania określony oprócz limitu czasu na poziomie zadania. Jeśli interwał limitu czasu na poziomie zadania upłynie przed ukończeniem kroku, zadanie uruchomione zostanie zakończone, nawet jeśli krok jest skonfigurowany z dłuższym interwałem limitu czasu. Aby uzyskać więcej informacji, zobacz Limity czasu.

W tym języku YAML jest uruchamiany nawet wtedy, PublishTestResults@2 gdy poprzedni krok zakończy się niepowodzeniem z powodu warunku succeededOrFailed().

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

Warunki

  • Tylko wtedy, gdy wszystkie poprzednie zależności bezpośrednie i pośrednie z tą samą pulą agentów zakończyły się pomyślnie. Jeśli masz różne pule agentów, te etapy lub zadania będą uruchamiane współbieżnie. Jest to ustawienie domyślne, jeśli nie ma warunku ustawionego w yaML.

  • Nawet jeśli poprzednia zależność nie powiodła się, chyba że przebieg został anulowany. Użyj succeededOrFailed() w pliku YAML dla tego warunku.

  • Nawet jeśli poprzednia zależność nie powiodła się, nawet jeśli przebieg został anulowany. Użyj always() w pliku YAML dla tego warunku.

  • Tylko wtedy, gdy poprzednia zależność nie powiodła się. Użyj failed() w pliku YAML dla tego warunku.

Cel kroku

Zadania są uruchamiane w kontekście wykonywania, który jest hostem agenta lub kontenerem. Pojedynczy krok może zastąpić jego kontekst, określając targetelement . Dostępne opcje to słowo host przeznaczone dla hosta agenta oraz wszystkie kontenery zdefiniowane w potoku. Na przykład:

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

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

W tym miejscu uruchamiane SampleTask na hoście i AnotherTask uruchamiane w kontenerze.

Liczba zadań, które zakończyły się niepowodzeniem

Użyj retryCountOnTaskFailure polecenia , aby określić liczbę ponownych prób w przypadku niepowodzenia zadania. Wartością domyślną jest zero.

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

Uwaga

  • Wymaga agenta w wersji 2.194.0 lub nowszej. Nieobsługiwane w przypadku zadań bez agenta.
  • Zadanie, które kończy się niepowodzeniem, ponawia próbę w sekundach. Czas oczekiwania między poszczególnymi ponownymi próbami wzrasta po każdej nieudanej próbie.
  • Nie ma założenia dotyczącego idempotentności zadania. Jeśli zadanie ma skutki uboczne (na przykład jeśli utworzył zasób zewnętrzny częściowo), może zakończyć się niepowodzeniem po drugim uruchomieniu.
  • Nie ma informacji o liczbie ponownych prób udostępnionych zadaniu.
  • Ostrzeżenie jest dodawane do dzienników zadań wskazujących, że nie powiodło się, zanim zostanie ponowione.
  • Wszystkie próby ponawiania próby wykonania zadania są wyświetlane w interfejsie użytkownika w ramach tego samego węzła zadania.

Potoki YAML nie są dostępne w programie TFS.

Zmienne środowiskowe

Potoki YAML są obsługiwane w usłudze Azure DevOps Server 2019 i nowszych wersjach.

Każde zadanie ma właściwość, która jest listą env par ciągów reprezentujących zmienne środowiskowe zamapowane na proces zadania.

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

Poniższy przykład uruchamia script krok, który jest skrótem do zadania wiersza polecenia, a następnie równoważną składnią zadania. W tym przykładzie przypisuje wartość do zmiennej środowiskowej, która jest używana do uwierzytelniania za pomocą interfejsu AZURE_DEVOPS_EXT_PAT wiersza polecenia usługi Azure DevOps.

# 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'

Instalatory narzędzi kompilacji (Azure Pipelines)

Instalatory narzędzi umożliwiają potokowi kompilacji instalowanie i kontrolowanie zależności. W szczególności można wykonywać następujące czynności:

  • Zainstaluj narzędzie lub środowisko uruchomieniowe na bieżąco (nawet w przypadku agentów hostowanych przez firmę Microsoft) na czas kompilacji ciągłej integracji.

  • Zweryfikuj aplikację lub bibliotekę dla wielu wersji zależności, takich jak Node.js.

Możesz na przykład skonfigurować potok kompilacji, aby uruchomić i zweryfikować aplikację dla wielu wersji Node.js.

Przykład: testowanie i weryfikowanie aplikacji w wielu wersjach Node.js

Utwórz plik azure-pipelines.yml w katalogu podstawowym projektu z następującą zawartością.

pool:
  vmImage: ubuntu-latest

steps:
# Node install
- task: UseNode@1
  displayName: Node install
  inputs:
    version: '16.x' # The version we're installing
# Write the installed version to the command line
- script: which node

Utwórz nowy potok kompilacji i uruchom go. Zobacz, jak jest uruchamiana kompilacja. Instalator narzędzia Node.js pobiera wersję Node.js, jeśli nie jest jeszcze na agencie. Skrypt wiersza polecenia rejestruje lokalizację wersji Node.js na dysku.

Potoki YAML nie są dostępne w programie TFS.

Zadania instalatora narzędzi

Aby zapoznać się z listą zadań instalatora narzędzi, zobacz Zadania instalatora narzędzi.

Wyłączanie zadań w polu i witrynie Marketplace

Na stronie ustawień organizacji można wyłączyć zadania witryny Marketplace, zadania wbudowane lub oba te zadania. Wyłączenie zadań witryny Marketplace może pomóc zwiększyć bezpieczeństwo potoków. Jeśli wyłączysz zarówno zadania wbudowane, jak i zadania witryny Marketplace, dostępne są tylko zadania instalowane przy użyciu tfx programu .

Pomoc i obsługa techniczna