Określanie zadań w potoku

Artykuł
04/04/2024

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

Potok można organizować w zadania. Każdy potok ma co najmniej jedno zadanie. Zadanie to seria kroków, które są uruchamiane sekwencyjnie jako jednostka. Innymi słowy, zadanie jest najmniejszą jednostką pracy, którą można zaplanować do uruchomienia.

Aby dowiedzieć się więcej na temat kluczowych pojęć i składników tworzących potok, zobacz Kluczowe pojęcia dotyczące nowych użytkowników usługi Azure Pipelines.

Usługa Azure Pipelines nie obsługuje priorytetu zadania dla potoków YAML. Aby kontrolować czas uruchamiania zadań, można określić warunki i zależności.

W najprostszym przypadku potok ma jedno zadanie. W takim przypadku nie musisz jawnie używać słowa kluczowegojob, chyba że używasz szablonu. Możesz bezpośrednio określić kroki w pliku YAML.

Ten plik YAML zawiera zadanie uruchamiane w agencie Hello worldhostowanym przez firmę Microsoft i zwraca dane wyjściowe .

pool:
  vmImage: 'ubuntu-latest'
steps:
- bash: echo "Hello world"

Możesz określić więcej właściwości tego zadania. W takim przypadku możesz użyć słowa kluczowego job .

jobs:
- job: myJob
  timeoutInMinutes: 10
  pool:
    vmImage: 'ubuntu-latest'
  steps:
  - bash: echo "Hello world"

Potok może mieć wiele zadań. W takim przypadku użyj słowa kluczowego jobs .

jobs:
- job: A
  steps:
  - bash: echo "A"

- job: B
  steps:
  - bash: echo "B"

Potok może zawierać wiele etapów, z których każdy ma wiele zadań. W takim przypadku użyj słowa kluczowego stages .

stages:
- stage: A
  jobs:
  - job: A1
  - job: A2

- stage: B
  jobs:
  - job: B1
  - job: B2

Pełna składnia określająca zadanie to:

- 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

Pełna składnia określająca zadanie to:

- 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

Jeśli głównym celem zadania jest wdrożenie aplikacji (w przeciwieństwie do kompilowania lub testowania aplikacji), możesz użyć specjalnego typu zadania o nazwie zadanie wdrożenia.

Składnia zadania wdrożenia to:

- deployment: string        # instead of job keyword, use deployment keyword
  pool:
    name: string
    demands: string | [ string ]
  environment: string
  strategy:
    runOnce:
      deploy:
        steps:
        - script: echo Hi!

Mimo że można dodać kroki dla zadań wdrażania w elemecie job, zalecamy użycie zadania wdrożenia. Zadanie wdrożenia ma kilka korzyści. Można na przykład wdrożyć w środowisku, które obejmuje korzyści, takie jak możliwość wyświetlenia historii wdrożonych elementów.

Typy zadań

Zadania mogą być różnego typu, w zależności od tego, gdzie są uruchamiane.

YAML
Klasyczny

Zadania puli agentów są uruchamiane na agencie w puli agentów.
Zadania serwera są uruchamiane na serwerze Azure DevOps Server.
Zadania kontenera są uruchamiane w kontenerze na agencie w puli agentów. Aby uzyskać więcej informacji na temat wybierania kontenerów, zobacz Definiowanie zadań kontenera.

YAML
Klasyczny

Zadania puli agentów są uruchamiane na agencie w puli agentów.
Zadania serwera są uruchamiane na serwerze Azure DevOps Server.

Zadania puli agentów

Są to najczęściej używane zadania i są uruchamiane na agencie w puli agentów.

W przypadku korzystania z agentów hostowanych przez firmę Microsoft każde zadanie w potoku pobiera nowego agenta.
Użyj żądań z własnymi agentami, aby określić, jakie możliwości musi mieć agent do uruchomienia zadania. Możesz uzyskać tego samego agenta dla kolejnych zadań, w zależności od tego, czy w puli agentów istnieje więcej niż jeden agent, który odpowiada wymaganiom potoku. Jeśli w puli jest tylko jeden agent, który odpowiada wymaganiom potoku, potok będzie czekać, aż ten agent będzie dostępny.

Uwaga

Wymagania i możliwości są przeznaczone do użytku z własnymi agentami, dzięki czemu zadania mogą być dopasowane do agenta spełniającego wymagania zadania. W przypadku korzystania z agentów hostowanych przez firmę Microsoft wybierasz obraz agenta, który spełnia wymagania zadania, więc chociaż istnieje możliwość dodania możliwości do agenta hostowanego przez firmę Microsoft, nie musisz używać funkcji z agentami hostowanymi przez firmę Microsoft.

YAML
Klasyczny

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

Lub wiele wymagań:

pool:
  name: myPrivateAgents
  demands:
  - agent.os -equals Darwin
  - anotherCapability -equals somethingElse
steps:
- script: echo hello world

Dowiedz się więcej o możliwościach agenta.

Zadania serwera

Zadania w zadaniu serwera są orkiestrowane i wykonywane na serwerze (Azure Pipelines lub TFS). Zadanie serwera nie wymaga agenta ani żadnych komputerów docelowych. Obecnie w zadaniu serwera jest obsługiwanych tylko kilka zadań. Maksymalny czas zadania serwera wynosi 30 dni.

Zadania bez agenta obsługiwane

Obecnie w przypadku zadań bez agenta obsługiwane są tylko następujące zadania:

Ponieważ zadania są rozszerzalne, można dodać więcej zadań bez agentów przy użyciu rozszerzeń. Domyślny limit czasu dla zadań bez agenta wynosi 60 minut.

YAML
Klasyczny

Pełna składnia określająca zadanie serwera to:

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

Można również użyć uproszczonej składni:

jobs:
- job: string
  pool: server # note: the value 'server' is a reserved keyword which indicates this is an agentless job

Zależności

Podczas definiowania wielu zadań na jednym etapie można określić zależności między nimi. Potoki muszą zawierać co najmniej jedno zadanie bez zależności. Domyślnie zadania potoku YAML usługi Azure DevOps są uruchamiane równolegle, chyba że wartość jest ustawiona dependsOn .

Uwaga

Każdy agent może uruchamiać tylko jedno zadanie naraz. Aby uruchomić wiele zadań równolegle, należy skonfigurować wielu agentów. Potrzebne są również wystarczające zadania równoległe.

YAML
Klasyczny

Składnia definiowania wielu zadań i ich zależności jest następująca:

jobs:
- job: string
  dependsOn: string
  condition: string

Przykładowe zadania kompilujące sekwencyjnie:

jobs:
- job: Debug
  steps:
  - script: echo hello from the Debug build
- job: Release
  dependsOn: Debug
  steps:
  - script: echo hello from the Release build

Przykładowe zadania, które są kompilujące równolegle (bez zależności):

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

Przykład wentylatora:

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

Przykład wentylatora:

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

Warunki

Możesz określić warunki, w których każde zadanie jest uruchamiane. Domyślnie zadanie jest uruchamiane, jeśli nie zależy od żadnego innego zadania lub czy wszystkie zadania, od których zależy, zostały ukończone i zakończyły się pomyślnie. To zachowanie można dostosować, wymuszając uruchomienie zadania, nawet jeśli poprzednie zadanie zakończy się niepowodzeniem lub przez określenie warunku niestandardowego.

YAML
Klasyczny

Przykład uruchamiania zadania na podstawie stanu uruchamiania poprzedniego zadania:

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

Przykład użycia warunku niestandardowego:

jobs:
- job: A
  steps:
  - script: echo hello

- job: B
  dependsOn: A
  condition: and(succeeded(), eq(variables['build.sourceBranch'], 'refs/heads/main'))
  steps:
  - script: echo this only runs for master

Można określić, że zadanie jest uruchamiane na podstawie wartości zmiennej wyjściowej ustawionej w poprzednim zadaniu. W takim przypadku można używać zmiennych ustawionych tylko w zadaniach zależnych bezpośrednio:

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

Limity czasu

Aby uniknąć zajmowania zasobów, gdy zadanie nie odpowiada lub oczekiwanie trwa zbyt długo, zalecamy ustawienie limitu czasu, w jakim zadanie może być wykonywane. Użyj ustawienia limitu czasu zadania, aby określić w minutach limit czasu, w jakim może być wykonywane zadanie. Ustawienie wartości na zero oznacza, że zadanie może zostać uruchomione:

Na zawsze na własnych agentach
Przez 360 minut (6 godzin) na agentach hostowanych przez firmę Microsoft z publicznym projektem i repozytorium publicznym
Przez 60 minut w przypadku agentów hostowanych przez firmę Microsoft z prywatnym projektem lub repozytorium prywatnym (chyba że zostanie opłacona dodatkowa pojemność )

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

YAML
Klasyczny

Parametr timeoutInMinutes umożliwia ustawienie limitu czasu wykonywania zadania. Jeśli nie zostanie określony, wartość domyślna to 60 minut. Jeśli 0 zostanie określony, zostanie użyty maksymalny limit (opisany powyżej).

Ustawienie cancelTimeoutInMinutes umożliwia ustawienie limitu czasu anulowania zadania, gdy zadanie wdrożenia ma być uruchomione, jeśli poprzednie zadanie nie powiodło się. Jeśli nie zostanie określony, wartość domyślna to 5 minut. Wartość powinna być w zakresie od 1 do 35790 minut.

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

Limity czasu mają następujący poziom pierwszeństwa.

W przypadku agentów hostowanych przez firmę Microsoft zadania są ograniczone do czasu ich działania na podstawie typu projektu i tego, czy są uruchamiane przy użyciu płatnego zadania równoległego. Gdy upłynie interwał limitu czasu zadania hostowanego przez firmę Microsoft, zadanie zostanie zakończone. W przypadku agentów hostowanych przez firmę Microsoft zadania nie mogą być uruchamiane dłużej niż w tym interwale, niezależnie od limitu czasu na poziomie zadania określonego w zadaniu.
Limit czasu skonfigurowany na poziomie zadania określa maksymalny czas trwania zadania do uruchomienia. Gdy upłynie interwał limitu czasu na poziomie zadania, zadanie zostanie zakończone. Jeśli zadanie jest uruchamiane w agencie hostowanym przez firmę Microsoft, ustawienie limitu czasu poziomu zadania na interwał większy niż wbudowany limit czasu na poziomie zadania hostowanego przez firmę Microsoft nie ma żadnego wpływu i jest używany limit czasu zadania hostowanego przez firmę Microsoft.
Możesz również ustawić limit czasu dla każdego zadania indywidualnie — zobacz opcje sterowania zadaniami. Jeśli interwał limitu czasu na poziomie zadania upłynie przed ukończeniem zadania, zadanie uruchomione zostanie zakończone, nawet jeśli zadanie jest skonfigurowane z dłuższym interwałem limitu czasu.

Konfiguracja wielu zadań

Z jednego zadania, które tworzysz, można uruchamiać wiele zadań na wielu agentach równolegle. Przykłady obejmują:

Kompilacje z wieloma konfiguracjami: można równolegle tworzyć wiele konfiguracji. Można na przykład utworzyć aplikację Visual C++ dla obu debug release i konfiguracji na obu x86 platformach i x64 . Aby uzyskać więcej informacji, zobacz Visual Studio Build — wiele konfiguracji dla wielu platform.
Wdrożenia z wieloma konfiguracjami: można uruchomić wiele wdrożeń równolegle, na przykład do różnych regionów geograficznych.
Testowanie wielu konfiguracji: można uruchomić równoległe testowanie wielu konfiguracji.
Wiele konfiguracji zawsze generuje co najmniej jedno zadanie, nawet jeśli zmienna z wieloma konfiguracjami jest pusta.

YAML
Klasyczny

Strategia matrix umożliwia wielokrotne wysyłanie zadania z różnymi zestawami zmiennych. Tag maxParallel ogranicza ilość równoległości. Następujące zadanie jest wysyłane trzy razy z wartościami Location i Browser ustawionymi zgodnie z określonymi. Jednak tylko dwa zadania są uruchamiane w tym samym czasie.

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

Uwaga

Nazwy konfiguracji macierzy (na przykład US_IE powyżej) muszą zawierać tylko podstawowe litery alfabetu łacińskiego (A-Z, a-z), cyfry i podkreślenia (_). Muszą zaczynać się od litery. Ponadto muszą mieć co najmniej 100 znaków.

Można również użyć zmiennych wyjściowych do wygenerowania macierzy. Może to być przydatne, jeśli musisz wygenerować macierz przy użyciu skryptu.

matrix akceptuje wyrażenie środowiska uruchomieniowego zawierające ciągyfikowany obiekt JSON. Ten obiekt JSON po rozwinięciu musi być zgodny ze składnią macierzy. W poniższym przykładzie kodowaliśmy ciąg JSON, ale można go wygenerować za pomocą języka skryptowego lub programu wiersza polecenia.

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

Aby uruchomić wiele zadań przy użyciu opcji wielokonfiguracyjne, należy zidentyfikować zmienną o nazwie mnożnik i określić listę wartości dla tego mnożnika. Oddzielne zadanie jest uruchamiane dla każdej wartości na liście. Aby używać mnożników do kompilowania lub wdrażania, należy:

Zdefiniuj co najmniej jedną zmienną na karcie Zmienne potoku lub w grupie zmiennych. Każda zmienna, znana w tym kontekście jako zmienna mnożnika , musi być zdefiniowana jako rozdzielana przecinkami lista wartości, które mają zostać przekazane indywidualnie do agentów.
Wprowadź nazwę zmiennej mnożnika bez $ nawiasów i jako wartość parametru Mnożnik . Używanie zmiennej tajnej jako zmiennej mnożnika nie jest obsługiwane.
Jeśli chcesz wykonać zadanie dla więcej niż jednej zmiennej mnożnika, wprowadź nazwy zmiennych jako listę rozdzielaną przecinkami — pomijając $ nawiasy i dla każdego z nich.
Jeśli chcesz ograniczyć liczbę agentów używanych podczas wdrażania do liczby mniejszej niż skonfigurowano dla subskrypcji, wprowadź wartość parametru Maksymalna liczba agentów .

Można na przykład zdefiniować dwie zmienne o nazwie Location (Lokalizacja ) i Browser (Przeglądarka) w następujący sposób:

Lokalizacja = US,Europe
Przeglądarka = IE,Chrome,Edge,Firefox

Poniższa konfiguracja wykonuje wdrożenie osiem razy przy użyciu maksymalnie czterech agentów w dowolnym momencie:

Mnożników = Location,Browser
Maksymalna liczba agentów = 4

W przypadku wielu konfiguracji można uruchamiać wiele zadań, z których każda ma inną wartość dla jednej lub większej liczby zmiennych (mnożników). Jeśli chcesz uruchomić to samo zadanie na wielu agentach, możesz użyć opcji równoległości dla wielu agentów . Powyższy przykład fragmentowania testu można wykonać za pomocą opcji wielu agentów.

Krojenie

Zadanie agenta może służyć do równoległego uruchamiania zestawu testów. Na przykład można uruchomić duży pakiet 1000 testów na jednym agencie. Możesz też użyć dwóch agentów i uruchomić 500 testów na każdym z nich równolegle.

Aby zastosować fragmentowanie, zadania w zadaniu powinny być wystarczająco inteligentne, aby zrozumieć fragment, do którego należą.

Zadanie testowe programu Visual Studio to jedno z takich zadań, które obsługuje fragmentowanie testowe. Jeśli zainstalowano wielu agentów, możesz określić, w jaki sposób zadanie testowe programu Visual Studio jest uruchamiane równolegle na tych agentach.

YAML
Klasyczny

Strategia parallel umożliwia wielokrotne duplikowanie zadania. Zmienne System.JobPositionInPhase i System.TotalJobsInPhase są dodawane do każdego zadania. Zmienne mogą być następnie używane w skryptach do dzielenia pracy między zadaniami. Zobacz Równoległe i wiele wykonań przy użyciu zadań agenta.

Następujące zadanie jest wysyłane pięć razy z wartościami System.JobPositionInPhase i System.TotalJobsInPhase ustawionymi odpowiednio.

jobs:
- job: Test
  strategy:
    parallel: 5

Zmienne zadania

Jeśli używasz języka YAML, zmienne można określić w zadaniu. Zmienne mogą być przekazywane do danych wejściowych zadań przy użyciu składni makr $(variableName) lub dostępnej w skrypecie przy użyciu zmiennej etapowej.

YAML
Klasyczny

Oto przykład definiowania zmiennych w zadaniu i używania ich w ramach zadań podrzędnych.

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"

Aby uzyskać informacje na temat używania warunku, zobacz Określanie warunków.

Obszar roboczy

Po uruchomieniu zadania puli agentów program tworzy obszar roboczy na agencie. Obszar roboczy to katalog, w którym pobiera źródło, uruchamia kroki i generuje dane wyjściowe. Do katalogu obszaru roboczego można odwoływać się w zadaniu przy użyciu Pipeline.Workspace zmiennej . W tym celu tworzone są różne podkatalogi:

Build.SourcesDirectory to miejsce, w którym zadania pobierają kod źródłowy aplikacji.
Build.ArtifactStagingDirectory to miejsce, w którym zadania pobierają artefakty potrzebne do potoku lub przekazywania artefaktów przed ich opublikowaniem.
Build.BinariesDirectory to miejsce, w którym zadania zapisują swoje dane wyjściowe.
Common.TestResultsDirectory to miejsce, w którym zadania przekazują wyniki testów.

YAML
Klasyczny

Element $(Build.ArtifactStagingDirectory) i $(Common.TestResultsDirectory) są zawsze usuwane i tworzone ponownie przed każdą kompilacją.

Po uruchomieniu potoku na własnym agencie domyślnie żaden z podkatalogów innych niż $(Build.ArtifactStagingDirectory) i $(Common.TestResultsDirectory) nie jest czyszczony między dwoma kolejnymi przebiegami. W związku z tym można wykonywać przyrostowe kompilacje i wdrożenia, pod warunkiem, że zadania są implementowane w celu ich użycia. To zachowanie można zastąpić przy użyciu workspace ustawienia w zadaniu.

Ważne

Opcje czyszczenia obszaru roboczego mają zastosowanie tylko dla własnych agentów. Zadania są zawsze uruchamiane na nowym agencie z agentami hostowanymi przez firmę Microsoft.

- job: myJob
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Po określeniu clean jednej z opcji są one interpretowane w następujący sposób:

outputs: Usuń Build.BinariesDirectory przed uruchomieniem nowego zadania.
resources: Usuń Build.SourcesDirectory przed uruchomieniem nowego zadania.
all: Usuń cały Pipeline.Workspace katalog przed uruchomieniem nowego zadania.

  jobs:
  - deployment: MyDeploy
    pool:
      vmImage: 'ubuntu-latest'
    workspace:
      clean: all
    environment: staging

Uwaga

W zależności od możliwości agenta i wymagań potoku każde zadanie może być kierowane do innego agenta w puli hostowanej samodzielnie. W związku z tym można uzyskać nowego agenta dla kolejnych przebiegów potoku (lub etapów lub zadań w tym samym potoku), więc nie jest to gwarancja, że kolejne uruchomienia, zadania lub etapy będą mogły uzyskać dostęp do danych wyjściowych z poprzednich przebiegów, zadań lub etapów. Można skonfigurować możliwości agenta i wymagania potoku, aby określić, którzy agenci są przyzwyczajeni do uruchamiania zadania potoku, ale chyba że istnieje tylko jeden agent w puli, który spełnia wymagania, nie ma gwarancji, że kolejne zadania będą używać tego samego agenta co poprzednie zadania. Aby uzyskać więcej informacji, zobacz Określanie wymagań.

Oprócz czyszczenia obszaru roboczego można również skonfigurować czyszczenie, konfigurując ustawienie Czyszczenie w interfejsie użytkownika ustawień potoku. Jeśli ustawienie Clean (Czyszczenie) ma wartość true( jest również jego wartością domyślną), jest równoważne określeniu dla każdego kroku wyewidencjonowania clean: true w potoku. Po określeniu clean: truepolecenia uruchomisz git clean -ffdx polecenie , a następnie git reset --hard HEAD przed pobraniem usługi Git. Aby skonfigurować ustawienie Czyszczenie :

Edytuj potok, wybierz pozycję ..., a następnie wybierz pozycję Wyzwalacze.
Wybierz pozycję YAML, Pobierz źródła i skonfiguruj odpowiednie ustawienie Wyczyść . Wartość domyślna to true.

Po uruchomieniu potoku na własnym agencie domyślnie żaden z podkatalogów nie jest czyszczony między dwoma kolejnymi przebiegami. W związku z tym można uruchamiać kompilacje przyrostowe i wdrożenia, pod warunkiem, że zadania są implementowane w tym celu. Można jednak zastąpić to zachowanie przy użyciu Clean build opcji w ramach Get sources zadania. Opcje różnią się w zależności od typu używanego repozytorium.

Pobieranie artefaktu

Ten przykładowy plik YAML publikuje artefakt WebSite , a następnie pobiera artefakt do $(Pipeline.Workspace). Zadanie Wdróż jest uruchamiane tylko wtedy, gdy zadanie kompilacji zakończy się pomyślnie.

YAML
Klasyczny

# 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: $(Pipeline.Workspace)

  dependsOn: Build
  condition: succeeded()

Aby uzyskać informacje o korzystaniu z funkcji dependsOn i warunku, zobacz Określanie warunków.

Dostęp do tokenu OAuth

Skrypty uruchomione w zadaniu umożliwiają dostęp do bieżącego tokenu zabezpieczającego usługi Azure Pipelines lub TFS OAuth. Token może służyć do uwierzytelniania w interfejsie API REST usługi Azure Pipelines.

YAML
Klasyczny

Token OAuth jest zawsze dostępny dla potoków YAML. Musi być jawnie zamapowany na zadanie lub krok przy użyciu polecenia env. Oto przykład:

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)

Udostępnij za pośrednictwem

Określanie zadań w potoku

Definiowanie pojedynczego zadania

Typy zadań

Zadania puli agentów

Zadania serwera

Zadania bez agenta obsługiwane

Zależności

Warunki

Limity czasu

Konfiguracja wielu zadań

Krojenie

Zmienne zadania

Obszar roboczy

Pobieranie artefaktu

Dostęp do tokenu OAuth

Co dalej?

Opinia

Dodatkowe zasoby