Udostępnij za pośrednictwem

Zasoby w potokach YAML

  • Artykuł

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

W tym artykule omówiono zasoby dla ciągów YAML. Zasób to wszystko, co jest używane przez potok, a znajduje się poza nim. Po zdefiniowaniu zasobu można z niego korzystać w dowolnym miejscu w potoku.

Zasoby zapewniają pełną śledzność usług, z których korzysta kolejka, w tym wersję, artefakty, powiązane zatwierdzenia i elementy robocze. Przepływy pracy metodyki DevOps można w pełni zautomatyzować, subskrybując wyzwalanie zdarzeń w zasobach.

Schemat zasobów

Zasoby w języku YAML reprezentują źródła potoków, kompilacji, repozytoriów, kontenerów, pakietów i elementów webhook. Aby uzyskać pełne informacje o schemacie, zobacz definicję zasobów w dokumentacji schematu YAML dla usługi Azure Pipelines.

Gdy zasób uruchamia potok, ustawiane są następujące zmienne:

resources.triggeringAlias
resources.triggeringCategory

Zmienna Build.Reason musi mieć ResourceTrigger wartość dla ustawienia tych wartości. Wartości są puste, jeśli dany zasób nie wywołał uruchomienia potoku.

Definicja zasobu potoków

Jeśli masz pipeline, który generuje artefakty, możesz używać tych artefaktów, definiując pipelines zasób. Tylko Azure Pipelines może używać zasobu pipelines. Możesz ustawić wyzwalacze dla przepływów pracy ciągłego wdrażania (CD) na zasobie pipeline.

W definicji zasobu, pipeline to unikalna wartość, której można użyć, aby odnieść się do zasobu potoku na późniejszym etapie potoku. Nazwa source jest nazwą potoku, który wygenerował artefakt potoku. Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.pipelines.pipeline.

Etykieta zdefiniowana przez pipeline służy do odniesienia się do zasobu potoku z innych jego części, na przykład podczas używania zmiennych zasobów potoku lub pobierania artefaktów. Aby uzyskać alternatywny sposób pobierania artefaktów z potoku, zobacz Pobieranie artefaktów.

Ważne

Podczas definiowania wyzwalacza zasobu potoku:

  • pipeline Jeśli zasób pochodzi z tego samego repozytorium co bieżący potok, lub self wyzwolenie odbywa się w tej samej gałęzi i zatwierdzeniu, na którym jest zgłaszane zdarzenie.
  • Jeśli zasób potoku pochodzi z innego repozytorium, bieżący potok jest wyzwalany w domyślnej pipeline gałęzi repozytorium zasobów.

Przykładowe definicje zasobów potoku

Poniższy przykład wykorzystuje artefakty z linii produkcyjnej w ramach tego samego projektu.

resources:
  pipelines:
  - pipeline: SmartHotel-resource # identifier to use in pipeline resource variables
    source: SmartHotel-CI # name of the pipeline that produces the artifacts

Aby korzystać z potoku z innego projektu, należy dołączyć nazwę projektu i nazwę źródła. W poniższym przykładzie użyto branch metody do rozwiązania domyślnej wersji, gdy potok jest wyzwalany ręcznie lub zgodnie z harmonogramem. Dane wejściowe dotyczące gałęzi nie mogą zawierać symboli wieloznacznych.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Przykład poniżej pokazuje zasób rurociągu z prostym wyzwalaczem.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger: true

W poniższym przykładzie przedstawiono zasób trigger potoku z kondycjami gałęzi.

resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
      - releases/*
      - resources.triggeringAlias

W poniższym przykładzie użyto stages filtrów do oceny kondycji wyzwalających dla potoków CD. Etapy używają AND operatora . Po pomyślnym zakończeniu wszystkich podanych etapów uruchamiany jest ciąg dostarczania oprogramowania (CD pipeline).

resources:
  pipelines:
  - pipeline: MyCIAlias  
    project: Fabrikam  
    source: Farbrikam-CI  
    trigger:    
      stages:
      - PreProduction
      - Production

W poniższym przykładzie użyto tags filtrów do domyślnej oceny wersji oraz wyzwalaczy. Tagi używają AND operatora .

Element tags jest ustawiany w potoku continuous integration (CI) lub continuous deployment (CD). Te tagi różnią się od tagów ustawionych w gałęziach w repozytorium Git.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    tags: 
    - Production 
    trigger:
      tags:
      - Production
      - Signed

Ocena wersji artefaktu potoków

Wersja artefaktu w potoku przepływu zasobów zależy od tego, jak potok jest wyzwalany.

Wyzwalacz ręczny lub zaplanowany

Jeśli uruchomienie potoku jest wyzwalane ręcznie lub zaplanowane, wartości właściwości version, branch i tags definiują wersję artefaktu. Dane branch wejściowe nie mogą mieć symboli wieloznacznych. Właściwości tags używają operatora AND.

Określone właściwości Wersja artefaktu
version Artefakty z kompilacji, które mają określony numer uruchomienia
branch Artefakty z najnowszego builda wykonanego w określonej gałęzi
tags lista Artefakty z najnowszej kompilacji zawierającej wszystkie określone tagi
branch i tags lista Artefakty z najnowszej kompilacji utworzonej w określonej gałęzi, która zawiera wszystkie wskazane tagi
version i branch Artefakty z kompilacji z określonym numerem uruchomienia i określoną gałęzią.
Brak Artefakty z najnowszej kompilacji we wszystkich gałęziach kodu

Poniższa pipeline definicja zasobu wykorzystuje właściwości branch i tags do oceny domyślnej wersji, gdy potok jest uruchamiany ręcznie lub według harmonogramu. Po ręcznym wyzwoleniu potoku do uruchomienia, wersja artefaktów potoku MyCIAlias to najnowsza kompilacja wykonana w gałęzi main, która zawiera tagi Production i PrepProduction.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main
    tags:
    - Production
    - PreProduction

Wyzwalacz zakończenia potoku zasobów

Gdy potok zostanie wyzwolony z powodu ukończenia jednego z jego potoków zasobów, wersja artefaktów jest wersją potoku wyzwalającego. Wartości właściwości version, branch i tags są ignorowane.

Określone wyzwalacze Wynik
branches Nowy przebieg potoku jest wyzwalany za każdym razem, gdy potok zasobów pomyślnie ukończy przebieg w jednej z include gałęzi.
tags Nowy przebieg potoku przetwarzania jest uruchamiany za każdym razem, gdy potok zasobów pomyślnie kończy przebieg oznaczony wszystkimi określonymi tagami.
stages Nowe uruchomienie potoku jest wyzwalane za każdym razem, gdy potok zasobu pomyślnie wykona określony element stages.
branches, tags i stages Nowe uruchomienie potoku jest wyzwalane za każdym razem, gdy potok zasobów spełnia wszystkie warunki gałęzi, tagów i etapów.
trigger: true Nowy przebieg potoku jest wyzwalany za każdym razem, gdy potok zasobów pomyślnie ukończy przebieg.
Nic Nie jest uruchamiany żaden nowy przebieg potoku, gdy potok zasobów pomyślnie zakończy swój przebieg.

Za każdym razem, gdy uruchamiany jest potok zasobów SmartHotel-CI:

  • Uruchamia się na jednej z gałęzi releases lub na gałęzi main.
  • Jest oznakowany zarówno Verified, jak i Signed
  • Kończy zarówno etapy Production i PreProduction
resources:
  pipelines:
  - pipeline: SmartHotel
    project: DevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Pobieranie artefaktu potoku

Krok download pobiera artefakty skojarzone z aktualnym uruchomieniem lub innym zasobem potoku.

Wszystkie artefakty z bieżącego pipeline'u i wszystkich jego pipeline zasobów są automatycznie pobierane i udostępniane na początku każdego zadania wdrożenia. To zachowanie można zastąpić, ustawiając download na none, lub przez określenie innego identyfikatora zasobu potoku.

Zwykłe artefakty zadań nie są pobierane automatycznie. W razie potrzeby użyj download jawnie.

Artefakty z pipeline zasobu są pobierane do katalogu $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Aby uzyskać więcej informacji, zobacz Publikowanie i pobieranie artefaktów pipeline.

Właściwość opcjonalna artifact określa nazwy artefaktów. Jeśli nie określono inaczej, zostaną pobrane wszystkie dostępne artefakty. Właściwość opcjonalna patterns definiuje wzorce reprezentujące pliki do uwzględnienia. Aby uzyskać pełne informacje o schemacie, zobacz definicję steps.download.

- job: deploy_windows_x86_agent
  steps:
  - download: SmartHotel
    artifact: WebTier1
    patterns: '**/*.zip'

Zmienne zasobów potoku

W każdym uruchomieniu metadane zasobu potoku są dostępne dla wszystkich zadań jako wstępnie zdefiniowane zmienne. Te zmienne są dostępne dla Twojego potoku tylko w czasie wykonywania i dlatego nie można ich używać w wyrażeniach szablonów, które są oceniane w czasie kompilacji potoku.

Aby uzyskać więcej informacji, zobacz Pipeline resource metadata as predefined variables (Metadane zasobów potoku jako wstępnie zdefiniowane zmienne). Aby dowiedzieć się więcej na temat składni zmiennych, zobacz Definiowanie zmiennych.

Poniższy przykład zwraca zdefiniowane wartości zmiennych dla zasobu potoku myresourcevars.

resources:
  pipelines:
  - pipeline: myresourcevars
    source: mypipeline
    trigger: true 

steps:
- script: |
    echo $(resources.pipeline.myresourcevars.pipelineID)
    echo $(resources.pipeline.myresourcevars.runName)
    echo $(resources.pipeline.myresourcevars.runID)
    echo $(resources.pipeline.myresourcevars.runURI)
    echo $(resources.pipeline.myresourcevars.sourceBranch)
    echo $(resources.pipeline.myresourcevars.sourceCommit)
    echo $(resources.pipeline.myresourcevars.sourceProvider)
    echo $(resources.pipeline.myresourcevars.requestedFor)
    echo $(resources.pipeline.myresourcevars.requestedForID)

Kompiluje definicję zasobu

Jeśli masz zewnętrzny system kompilacji ciągłej integracji (CI), który generuje artefakty, możesz korzystać z artefaktów za pomocą builds zasobów. Zasób build może pochodzić z dowolnego zewnętrznego systemu ciągłej integracji, takiego jak Jenkins, TeamCity lub CircleCI.

Kategoria builds jest rozszerzalna. Możesz napisać rozszerzenie do korzystania z artefaktów z usługi kompilacji i wprowadzić nowy typ usługi w ramach programu builds.

W definicji build wartość domyślna version to najnowsza pomyślna kompilacja. Właściwość trigger nie jest domyślnie włączona i musi być jawnie ustawiona. Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.builds.build.

W poniższym przykładzie serwer Jenkins jest zasobem type.

resources:
  builds:
  - build: Spaceworkz
    type: Jenkins
    connection: MyJenkinsServer 
    source: SpaceworkzProj   # name of the Jenkins source project
    trigger: true

Ważne

Wyzwalacze są obsługiwane tylko dla hostowanego serwera Jenkins, gdy Azure DevOps ma bezpośredni dostęp do serwera Jenkins.

Zadanie downloadBuild

Artefakty build zasobów nie są automatycznie pobierane w zadaniach i zadaniach wdrażania. Aby korzystać z artefaktów z build zasobu w ramach swoich zadań, należy wyraźnie dodać downloadBuild zadanie. Zachowanie pobierania dla każdego wdrożenia lub zadania można dostosować.

To zadanie automatycznie rozwiązuje odpowiednie zadanie pobierania dla typu zasobu definiowanego przez środowisko uruchomieniowe build. Artefakty z build zasobu są pobierane do folderu $(PIPELINE.WORKSPACE)/<build-identifier>/.

W definicji downloadBuild określasz zasób, z którego pobierane są artefakty. Właściwość opcjonalna artifact określa artefakty do pobrania. Jeśli nie zostanie to określone, zostaną pobrane wszystkie artefakty skojarzone z zasobem.

Właściwość opcjonalna patterns definiuje ścieżkę minimatch lub listę ścieżek minimatch do pobrania. Jeśli jest puste, cały artefakt zostanie pobrany. Na przykład poniższy fragment kodu pobiera tylko pliki *.zip .

- job: deploy_windows_x86_agent
  steps:
  - downloadBuild: Spaceworkz
    patterns: '**/*.zip'

Aby uzyskać pełne informacje o schemacie, zobacz definicję steps.downloadBuild.

Definicja zasobu repozytorium

Słowo repository kluczowe umożliwia określenie repozytorium zewnętrznego. Możesz użyć tego zasobu, jeśli twój potok zawiera szablony w innym repozytorium lub chcesz użyć wyewidencjonowania wielu repozytoriów z repozytorium wymagającym połączenia z usługą. Należy poinformować system o tych repozytoriach.

Na przykład:

resources:
  repositories:
  - repository: common
    type: github
    name: Contoso/CommonTools
    endpoint: MyContosoServiceConnection

Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.repositories.repository.

Typy zasobów repozytorium

Usługa Azure Pipelines obsługuje następujące wartości dla typu repozytorium: git, , githubgithubenterprisei bitbucket.

  • Typ git odnosi się do repozytoriów Git usługi Azure Repos.
  • Repozytoria GitHub Enterprise wymagają połączenia usługi GitHub Enterprise w celu autoryzacji.
  • Repozytoria usługi Bitbucket Cloud wymagają połączenia usługi Bitbucket w chmurze na potrzeby autoryzacji.
Typ Wartość nazwy Przykład
type: git Inne repozytorium w tym samym projekcie lub tej samej organizacji. Ten sam projekt: name: otherRepo
Inny projekt w tej samej organizacji: name: otherProject/otherRepo.
type: github Pełna nazwa repozytorium GitHub, w tym użytkownika lub organizacji. name: Microsoft/vscode
type: githubenterprise Pełna nazwa repozytorium GitHub Enterprise, w tym użytkownika lub organizacji. name: Microsoft/vscode
type: bitbucket Pełna nazwa repozytorium Usługi Bitbucket Cloud, w tym użytkownika lub organizacji. name: MyBitbucket/vscode

Zmienne zasobów repozytorium

W każdym przebiegu następujące metadane zasobu repozytorium są dostępne dla wszystkich zadań w postaci zmiennych środowiska uruchomieniowego. <Alias> to identyfikator, który nadajesz zasobowi repozytorium.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url

Poniższy przykład zawiera zasób repozytorium z aliasem common, więc dostęp do zmiennych zasobów repozytorium jest uzyskiwany przy użyciu polecenia resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"

W każdej iteracji dostępne dla wszystkich zadań są następujące metadane zasobu repozytorium w postaci zmiennych uruchomieniowych. <Alias> to identyfikator, który nadajesz zasobowi repozytorium.

resources.repositories.<Alias>.name
resources.repositories.<Alias>.ref
resources.repositories.<Alias>.type
resources.repositories.<Alias>.id
resources.repositories.<Alias>.url
resources.repositories.<Alias>.version

Poniższy przykład zawiera zasób repozytorium z aliasem common, więc dostęp do zmiennych zasobów repozytorium jest uzyskiwany przy użyciu polecenia resources.repositories.common.*.

resources:
  repositories:
    - repository: common
      type: git
      ref: main
      name: Repo

variables:
  ref: $[ resources.repositories.common.ref ]
  name: $[ resources.repositories.common.name ]
  id: $[ resources.repositories.common.id ]
  type: $[ resources.repositories.common.type ]
  url: $[ resources.repositories.common.url ]
  version: $[ resources.repositories.common.version ]

steps:
- bash: |
    echo "name = $(name)"
    echo "ref = $(ref)"
    echo "id = $(id)"
    echo "type = $(type)"
    echo "url = $(url)"
    echo "version = $(version)"

Pobierz słowo kluczowe dla repozytoriów

Repozytoria z zasobu repository nie są automatycznie synchronizowane w zadaniach. Użyj słowa kluczowego checkout , aby pobrać repozytorium zdefiniowane jako część repository zasobu. Aby uzyskać pełne informacje o schemacie, zobacz definicję steps.checkout.

Aby uzyskać więcej informacji, zapoznaj się z artykułem Korzystanie z wielu repozytoriów w potoku.

Definicja zasobu kontenerów

Jeśli musisz wykorzystywać obrazy kontenerów w swoich potokach CI/CD, możesz użyć zasobów containers. Zasób container może być publicznym lub prywatnym rejestrem platformy Docker lub wystąpieniem usługi Azure Container Registry.

Możesz użyć ogólnego obrazu zasobu kontenera jako części swojego zadania lub użyć tego zasobu dla zadań kontenera. Jeśli potok wymaga wsparcia jednego lub więcej serwisów, musisz utworzyć i połączyć się z kontenerami serwisów. Za pomocą woluminów można udostępniać dane między usługami.

Jeśli musisz używać obrazów z rejestru Docker w ramach przepływu pracy, możesz zdefiniować ogólny zasób kontenera. Nie jest wymagane żadne słowo kluczowe type. Na przykład:

resources:         
  containers:
  - container: smartHotel 
    endpoint: myDockerRegistry
    image: smartHotelApp

Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.containers.container.

Uwaga

Składnia umożliwiająca enabled: 'true' włączanie wyzwalaczy kontenera dla wszystkich tagów obrazów różni się od składni innych wyzwalaczy zasobów. Pamiętaj, aby użyć poprawnej składni dla określonych zasobów.

Typ zasobu usługi Azure Container Registry

Aby korzystać z obrazów Azure Container Registry, możesz użyć pierwszoklasowego zasobu kontenerowego acr. Można użyć tego typu zasobu jako części procesów roboczych oraz włączyć automatyczne wyzwalacze potoku pracy.

Do korzystania z wyzwalaczy potoku automatycznego potrzebujesz uprawnień współautora lub właściciela usługi Azure Container Registry. Aby uzyskać więcej informacji, zobacz Role i uprawnienia usługi Azure Container Registry.

Aby użyć typu zasobu acr, należy określić wartości azureSubscription, resourceGroup i repository dla rejestru kontenerów Azure. Na przykład:

resources:         
  containers:
  - container: petStore      
    type: acr  
    azureSubscription: ContosoConnection
    resourceGroup: ContosoGroup
    registry: petStoreRegistry
    repository: myPets
    trigger: 
      tags:
        include: 
        - production*

Uwaga

Ocena wyzwalacza odbywa się tylko w gałęzi domyślnej. Pamiętaj, aby ustawić poprawną gałąź domyślną lub scalić plik YAML z bieżącą gałęzią domyślną. Aby uzyskać więcej informacji na temat zmiany gałęzi domyślnej potoku, odwiedź Domyślną gałąź potoku.

Zmienne zasobów kontenera

Po zdefiniowaniu kontenera jako zasobu metadane obrazu kontenera są przekazywane do potoku jako zmienne. Informacje, takie jak obraz, rejestr i szczegóły połączenia, są dostępne we wszystkich zadaniach używanych w zadaniach wdrażania kontenera.

Zmienne zasobów kontenera współpracują z platformą Docker i usługą Azure Container Registry. Nie można używać zmiennych zasobów kontenera dla kontenerów obrazów lokalnych. Zmienna location ma zastosowanie tylko do acr typu zasobów kontenera.

Poniższy przykład zawiera połączenie usługi Azure Resource Manager o nazwie arm-connection. Aby uzyskać więcej informacji, zobacz Rejestry kontenerów platformy Azure, repozytoria i obrazy.

resources:
  containers:
  - container: mycontainer
    type: ACR
    azureSubscription: arm-connection
    resourceGroup: rg-storage-eastus
    registry: mycontainerregistry
    repository: hello-world
    trigger:
      tags:
      - latest

steps:
- script: echo |
    echo $(resources.container.mycontainer.type)
    echo $(resources.container.mycontainer.registry)
    echo $(resources.container.mycontainer.repository)
    echo $(resources.container.mycontainer.tag)
    echo $(resources.container.mycontainer.digest)
    echo $(resources.container.mycontainer.URI)
    echo $(resources.container.mycontainer.location)

Definicja zasobu pakietów

Pakiety NuGet i npm GitHub można konsumować jako zasoby w potokach YAML. Aby włączyć automatyczne wyzwalacze potoku po wydaniu nowej wersji pakietu, ustaw trigger właściwość na true.

Podczas definiowania package zasobów określ repozytorium</>nazwę< pakietu >we name właściwości i ustaw pakiet type jako NuGet lub npm. Aby korzystać z pakietów GitHub, użyj uwierzytelniania opartego na osobistym tokenie dostępu (PAT) i utwórz połączenie usługi GitHub korzystające z tokenu PAT.

Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.packages.package.

Domyślnie pakiety nie są automatycznie pobierane do zadań. Aby pobrać, użyj polecenia getPackage.

Poniższy przykład zawiera połączenie usługi GitHub o nazwie pat-contoso z pakietem npm usługi GitHub o nazwie contoso. Aby uzyskać więcej informacji, zobacz Pakiety GitHub.

resources:
  packages:
    - package: contoso
      type: npm
      connection: pat-contoso
      name: myname/contoso 
      version: 7.130.88 
      trigger: true

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

Definicja zasobu webhooków

Uwaga

Webhooki wprowadzono w usłudze Azure DevOps Server 2020.1.

Możesz korzystać z artefaktów i włączać automatyczne wyzwalacze za pomocą zasobów takich jak potoki, kontenery, kompilacje i pakiety. Nie można jednak używać tych zasobów do automatyzowania wdrożeń na podstawie zdarzeń zewnętrznych lub usług.

Zasób webhooks w potokach YAML umożliwia integrację potoków z usługami zewnętrznymi, takimi jak GitHub, GitHub Enterprise, Nexus i Artifactory, aby zautomatyzować przepływy pracy. Możesz subskrybować dowolne zdarzenia zewnętrzne za pośrednictwem webhooków i używać tych zdarzeń do wyzwalania swoich potoków.

Elementy webhook automatyzują przepływ pracy na podstawie dowolnego zewnętrznego zdarzenia elementu webhook, które nie jest obsługiwane przez zasoby pierwszej klasy, takie jak potoki, kompilacje, kontenery lub pakiety. Ponadto, w przypadku usług lokalnych, gdzie Azure DevOps nie ma dostępu do procesu, można skonfigurować webhooki na usłudze i automatycznie wyzwalać pipeline'y.

Aby zasubskrybować zdarzenie webhook, należy zdefiniować zasób webhook w potoku i podłączyć go do przychodzącego połączenia usługi webhook. Można również zdefiniować więcej filtrów dla zasobu webhooka na podstawie danych ładunku JSON, aby dostosować wyzwalacze dla każdego pipeline'u.

Za każdym razem, gdy połączenie usługi webhook odbiera zdarzenie webhook, uruchamiany jest nowy proces dla wszystkich potoków subskrybowanych na to zdarzenie webhook. Dane ładunku JSON można wykorzystywać w zadaniach jako zmienne, korzystając z formatu ${{ parameters.<WebhookAlias>.<JSONPath>}}.

Aby uzyskać pełne informacje o schemacie, zobacz definicję elementu resources.webhooks.webhook.

W poniższym przykładzie zdefiniowano zasób webhook.

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

steps:  
- script: echo ${{ parameters.WebHook.resource.message.title }}

Wyzwalacze webhooków

Aby skonfigurować wyzwalacze webhook, należy najpierw skonfigurować webhook w usłudze zewnętrznej, podając następujące informacje:

  • Adres URL żądania: https://dev.azure.com/<Azure DevOps organization>/_apis/public/distributedtask/webhooks/<webhook name>?api-version=6.0-preview
  • Wpis tajny (opcjonalnie): jeśli musisz zabezpieczyć ładunek JSON, podaj wartość wpisu tajnego.

Następnie utworzysz nowe połączenie usługi przychodzącego webhooka. W przypadku tego typu połączenia z usługą należy zdefiniować następujące informacje:

  • Nazwa WebHook: Taka sama jak WebHook utworzony w Twojej usłudze zewnętrznej.
  • Tajny (opcjonalnie): służy do weryfikowania skrótu HMAC-SHA1 ładunku w celu potwierdzenia przychodzącego żądania. Jeśli podczas tworzenia webhooka użyto sekretu, musisz podać ten sam sekret.
  • Nagłówek HTTP: Nagłówek HTTP w żądaniu zawierający wartość skrótu HMAC-SHA1 ładunku, służącą do weryfikacji żądania. Na przykład nagłówek żądania usługi GitHub to X-Hub-Signature.

Zrzut ekranu przedstawiający przychodzące połączenie usługi webhook.

Aby uruchomić potok przy użyciu webhooka, należy wysłać POST żądanie do https://dev.azure.com/<org_name>/_apis/public/distributedtask/webhooks/<webhook_connection_name>?api-version=6.0-preview. Ten punkt końcowy jest publicznie dostępny i nie wymaga autoryzacji. Żądanie powinno mieć treść podobną do następującego przykładu:

{
    "resource": {
        "message": {
            "title": "Hello, world!",
            "subtitle": "I'm using WebHooks!"
        }
    }
}

Uwaga

Uzyskiwanie dostępu do danych z treści żądania webhooka może prowadzić do nieprawidłowego kodu YAML. Na przykład krok - script: echo ${{ parameters.WebHook.resource.message }} potoku importuje cały komunikat JSON, co generuje nieprawidłowy plik YAML. Żaden ciąg wyzwolony za pośrednictwem tego webhooka nie jest uruchamiany, ponieważ wygenerowany kod YAML stał się nieprawidłowy.

Poniższy fragment kodu przedstawia kolejny przykład użycia filtrów webhook.

resources:
  webhooks:
    - webhook: MyWebhookTrigger          
      connection: MyWebhookConnection    
      filters:
        - path: repositoryName      
          value: maven-releases     
        - path: action
          value: CREATED
steps:
- task: PowerShell@2
  inputs:
    targetType: 'inline'
    script: |
      Write-Host ${{ parameters.MyWebhookTrigger.repositoryName}}
      Write-Host ${{ parameters.MyWebhookTrigger.component.group}}

Selektor wersji ręcznej dla zasobów

Po ręcznym wyzwoleniu potoku ciągłego wdrażania YAML, usługa Azure Pipelines automatycznie ocenia domyślne wersje zasobów zdefiniowanych w potoku na podstawie wprowadzonych danych. Jednak usługa Azure Pipelines uwzględnia pomyślne przebiegi ciągłej integracji tylko podczas oceniania domyślnej wersji dla zaplanowanych wyzwalaczy lub jeśli nie wybierzesz ręcznie wersji.

Narzędzie wyboru wersji zasobów umożliwia ręczne wybranie innej wersji podczas tworzenia procesu. Selektor wersji dla zasobów jest obsługiwany w przypadku zasobów związanych z potokiem, kompilacją, repozytorium, kontenerem oraz pakietem.

W przypadku zasobów potoku można wyświetlić wszystkie dostępne uruchomienia we wszystkich gałęziach, przeszukać je na podstawie numeru potoku lub gałęzi, a następnie wybrać uruchomienie zakończone powodzeniem, niepowodzone lub w toku. Ta elastyczność zapewnia, że możesz uruchomić potok ciągłego wdrażania, gdy jesteś pewny, że przebieg wygenerował wszystkie artefakty, których potrzebujesz. Nie musisz czekać na ukończenie procesu CI ani ponownie uruchamiać go z powodu niepowiązanego błędu w etapie.

Aby użyć selektora wersji zasobów, w okienku Uruchamianie potoku kliknij Zasoby, następnie wybierz zasób i określoną wersję z listy dostępnych wersji.

Zrzut ekranu przedstawiający selektor wersji zasobów repozytorium.

W przypadku zasobów, w których nie można pobrać dostępnych wersji, takich jak pakiety GitHub, selektor wersji udostępnia pole tekstowe, aby można było wprowadzić wersję do wyboru.

Autoryzacja zasobów w potokach YAML

Zasoby muszą być autoryzowane, zanim będą mogły być używane w potokach. Właściciele zasobów kontrolują użytkowników i procesy, które mogą uzyskiwać dostęp do swoich zasobów. Istnieje kilka sposobów na autoryzację potoku YAML do korzystania z zasobów.

  • Użyj doświadczenia w zarządzaniu zasobami, aby zezwolić wszystkim potokom na dostęp do zasobu. Na przykład grupy zmiennych i bezpieczne pliki są zarządzane na stronie Biblioteka w obszarze Potoki, a pule agentów i połączenia usług są zarządzane w ustawieniach programu Project. Ta autoryzacja jest wygodna, jeśli nie musisz ograniczać dostępu do zasobów, takich jak w przypadku zasobów testowych.

  • Podczas tworzenia potoku wszystkie zasoby, do których odwołuje się plik YAML, są automatycznie autoryzowane do użycia przez potok, jeśli masz rolę Użytkownika dla tych zasobów.

  • Jeśli dodasz zasób do pliku YAML i kompilacja zakończy się niepowodzeniem z powodu błędu, takiego jak Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., zostanie wyświetlona opcja autoryzowania zasobów w kompilacji, która zakończyła się niepowodzeniem.

    Jeśli jesteś członkiem roli Użytkownik dla zasobu, możesz wybrać tę opcję i autoryzować zasób w kompilacji, która zakończyła się niepowodzeniem. Po autoryzowanym zasobie możesz rozpocząć nową kompilację.

  • Sprawdź, czy role zabezpieczeń puli agentów dla projektu są poprawne.

Sprawdzanie zatwierdzenia zasobów

Możesz użyć sprawdzania zatwierdzenia i szablonów, aby ręcznie kontrolować, kiedy zasób ma być uruchomiony. W przypadku sprawdzania zatwierdzenia wymaganego szablonu można wymagać, aby dowolny potok używający zasobu lub środowiska rozszerzał się z określonego szablonu YAML.

Ustawienie wymaganego zatwierdzenia szablonu gwarantuje, że zasób jest używany tylko w określonych warunkach i zwiększa bezpieczeństwo. Aby dowiedzieć się więcej o tym, jak poprawić bezpieczeństwo potoku za pomocą szablonów, zobacz Korzystanie z szablonów dla bezpieczeństwa.

Identyfikowalność

Usługa Azure Pipelines zapewnia pełną możliwość śledzenia dowolnego zasobu używanego na poziomie zadania potoku lub wdrożenia.

Śledzenie rurociągu

Usługa Azure Pipelines zawiera następujące informacje dotyczące każdego uruchomienia potoku:

  • Jeśli zasób wyzwolił potok, zasób, który wyzwolił potok.
  • Wersja zasobu i wykorzystywane artefakty.
  • Zatwierdzenia skojarzone z każdym zasobem.
  • Elementy robocze skojarzone z każdym zasobem.

Śledzenie środowiska

Za każdym razem, gdy potok danych jest wdrażany w środowisku, można wyświetlić listę zasobów, które są zużywane. Widok obejmuje zasoby wykorzystywane w ramach zadań wdrożeniowych oraz powiązane z nimi zatwierdzenia i elementy robocze.

Zrzut ekranu przedstawiający zatwierdzenia w środowisku.

Skojarzone informacje o pipeline'ach ciągłego wdrażania w pipeline'ach CI

Aby zapewnić śledzenie na każdym etapie, możesz monitorować, które potoki ciągłego wdrażania używają określonego potoku ciągłej integracji za pośrednictwem elementu pipelines. Jeśli inne potoki korzystają z twojego potoku CI, zobaczysz kartę Skojarzone potoki w widoku Uruchamiania. Widok przedstawia wszystkie uruchomienia potoku YAML ciągłego wdrożenia (CD), które wykorzystują potok ciągłej integracji (CI) oraz artefakty z niego.

Zrzut ekranu przedstawiający informacje o potokach ciągłego wdrażania w potoku ciągłej integracji.

Problemy z wyzwalaczem zasobów

Nie można wykonać wyzwalaczy zasobów, ponieważ:

  • Źródło podanego połączenia z usługą jest nieprawidłowe, występują błędy składni w wyzwalaczu lub wyzwalacz nie jest skonfigurowany.
  • Warunki wyzwalacza nie zostały spełnione.

Aby sprawdzić, dlaczego wyzwalacze potoku nie wykonały się, wybierz pozycję menu Problemy z wyzwalaczami na stronie definicji potoku. Problemy z aktywacją są dostępne tylko dla zasobów innych niż repozytorium.

Zrzut ekranu przedstawiający problemy z wyzwalaczem na stronie głównej przepływu.

Na stronie Problemy z wyzwalaczem komunikaty o błędach i ostrzeżeniach opisują przyczynę niepowodzenia wyzwalacza.

Zrzut ekranu przedstawiający możliwość obsługi problemów z wyzwalaczem.

Często zadawane pytania

Kiedy należy używać zasobów potoków, skrótu pobierania lub zadania Pobierz artefakty potoku?

Użycie zasobu to sposób na korzystanie z artefaktów z potoku CI, jak również na konfigurowanie zautomatyzowanych wyzwalaczy. Zasób zapewnia pełny wgląd w proces, wyświetlając używaną wersję, artefakty, commity i elementy robocze. Podczas definiowania zasobu potoku skojarzone artefakty są automatycznie pobierane w zadaniach wdrażania.

Możesz użyć skrótu download, aby pobrać artefakty w zadaniach kompilacji lub zmienić domyślne pobieranie w zadaniach wdrażania. Aby uzyskać więcej informacji, zobacz definicję steps.download.

Zadanie Pobierz artefakty potoku nie zapewnia możliwości śledzenia ani wyzwalaczy, ale czasami warto używać tego zadania bezpośrednio. Na przykład może istnieć zadanie skryptu przechowywane w innym szablonie, które wymaga pobrania artefaktów z kompilacji. Możesz też nie chcieć dodać zasobu potoku do szablonu. Aby uniknąć zależności, możesz użyć zadania Pobierz artefakty potoku, aby przekazać wszystkie informacje o kompilacji do zadania.

Jak mogę wyzwolić uruchomienie potoku po zaktualizowaniu obrazu usługi Docker Hub?

Wyzwalacz zasobu kontenera nie jest dostępny dla potoków YAML w usłudze Docker Hub, dlatego należy skonfigurować klasyczny potok wydawniczy.

  1. Utwórz nowe połączenie usługi Docker Hub.
  2. Utwórz klasyczny potok wydania i dodaj artefakt usługi Docker Hub. Ustaw połączenie usługi i wybierz przestrzeń nazw, repozytorium, wersję i alias źródłowy.
  3. Wybierz wyzwalacz i włącz wyzwalacz ciągłego wdrażania, przełączając go na Włączony. Każdy push Docker do wybranego repozytorium tworzy wydanie.
  4. Utwórz nowy etap i zadanie. Dodaj dwa zadania: logowanie do Docker i Bash.
    • Zadanie Docker ma działanie login i loguje Cię do Docker Hub.
    • Zadanie Bash uruchamia docker pull <hub-user>/<repo-name>[:<tag>].

Jak mogę zweryfikować i rozwiązać problemy z moim webhookiem?

  1. Utwórz połączenie z usługą.

  2. Odnieś się do połączenia z usługą i nadaj nazwę webhookowi w sekcji webhooks.

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Uruchom swój pipeline. Element webhook jest tworzony na platformie Azure jako zadanie rozproszone dla organizacji.

  4. Wykonaj wywołanie interfejsu API z prawidłowym POST kodem JSON w treści na https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Jeśli otrzymasz odpowiedź z kodem statusu 200, webhook jest gotowy do użycia przez twoją linię przetwarzania.

Jeśli otrzymasz odpowiedź z kodem stanu 500 z błędem Cannot find webhook for the given webHookId ..., kod może znajdować się w gałęzi, która nie jest gałęzią domyślną. Aby rozwiązać ten problem:

  1. Wybierz pozycję Edytuj na stronie pipeline'u.
  2. Z menu Więcej akcji wybierz pozycję Wyzwalacze.
  3. Wybierz kartę YAML , a następnie wybierz pozycję Pobierz źródła.
  4. W obszarze Gałąź domyślna dla kompilacji ręcznych i zaplanowanych zaktualizuj gałąź funkcji.
  5. Wybierz Zapisz i zakolejkuj.
  6. Po pomyślnym uruchomieniu tego potoku wykonaj wywołanie interfejsu POST API z prawidłowym kodem JSON w treści na https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Powinieneś teraz otrzymać odpowiedź z kodem stanu 200.

Powiązana zawartość