Udostępnij za pośrednictwem

Typy zadań i użycie

  • Artykuł

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

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.

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.

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 kończą się powodzeniem. Jeśli masz różne pule agentów, te etapy lub zadania są uruchamiane współbieżnie. Ten warunek jest domyślny, jeśli w YAML nie ustawiono żadnego warunku.

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

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

  • Tylko wtedy, gdy poprzednia zależność zakończy się niepowodzeniem. 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ść domyślna to zero ponownych prób. Aby uzyskać więcej informacji na temat właściwości zadania, zobacz steps.task w schemacie YAML.

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

Uwaga

  • Wymaga agenta w wersji 2.194.0 lub nowszej. W usłudze Azure DevOps Server 2022 ponowne próby nie są obsługiwane w przypadku zadań bez agentów. Aby uzyskać więcej informacji, zobacz Aktualizacja usługi Azure DevOps 16 listopada 2021 r. — automatyczne ponawianie prób dla zadania, a aktualizacja usługi Azure DevOps 14 czerwca 2025 r. — ponowne próby dla zadań serwera.
  • Czas oczekiwania między poszczególnymi ponownymi próbami wzrasta po każdej nieudanej próbie. Pierwsze ponowienie próby odbywa się w sekundach.
  • 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

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'


- task: Bash@3
  inputs:
     targetType: # 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 dla Bash@3, a następnie równoważną składnią zadań. W tym przykładzie wartość jest przypisywana do zmiennej środowiskowej ENV_VARIABLE_NAME i odzwierciedla wartość .

# Using the script shortcut syntax
- script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

# Using the task syntax
- task: Bash@2
  inputs:
    script: echo "This is " $ENV_VARIABLE_NAME
  env:
    ENV_VARIABLE_NAME: "my value"
  displayName: 'echo environment variable'

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