Zasoby w potokach YAML

Artykuł
07/02/2024

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

W tym artykule omówiono zasoby dla potoków YAML. Zasób jest używany przez potok, który istnieje poza potokiem. Po zdefiniowaniu zasobu można go używać w dowolnym miejscu w potoku.

Zasoby zapewniają pełną możliwość śledzenia usług używanych przez potok, w tym wersję, artefakty, skojarzone 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 wyzwala potok, ustawiane są następujące zmienne:

resources.triggeringAlias
resources.triggeringCategory

Zmienna musi być ResourceTrigger dla Build.Reason tych wartości, aby można było ustawić. Wartości są puste, jeśli zasób nie wyzwolił uruchomienia potoku.

Definicja zasobu potoków

Jeśli masz potok, który generuje artefakty, możesz użyć artefaktów, definiując pipelines zasób. Zasób może być używany tylko w usłudze pipelines Azure Pipelines. Wyzwalacze można ustawić dla przepływów pracy ciągłego wdrażania (CD) w zasobie potoku.

W definicji zasobu jest unikatową wartością, pipeline której można użyć do odwołowania się do zasobu potoku w dalszej części potoku. Jest source to nazwa potoku, który wygenerował artefakt potoku. Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.pipelines.pipeline.

Etykieta zdefiniowana przez pipeline jest używana do odwoływania się do zasobu potoku z innych części potoku, na przykład w przypadku używania zmiennych zasobów potoku lub pobierania artefaktów. Aby uzyskać alternatywny sposób pobierania artefaktów 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 selfwyzwalacz jest zgodny z tą samą gałęzią i zatwierdzeniem, 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 używa artefaktów z potoku 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 gałęzi nie mogą mieć symboli wieloznacznych.

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

Poniższy przykład przedstawia zasób potoku 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 warunkami 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 warunków wyzwalacza dla potoków ciągłego wdrażania. Etapy używają AND operatora . Po pomyślnym zakończeniu wszystkich podanych etapów potok ciągłego wdrażania wyzwala.

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 i wyzwalaczy. Tagi używają AND operatora .

Element tags jest ustawiany w potoku ciągłej integracji lub ciągłego wdrażania. 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 potoku zasobu zależy od sposobu wyzwalania potoku.

Wyzwalacz ręczny lub zaplanowany

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

Określone właściwości	Wersja artefaktu
`version`	Artefakty z kompilacji, które mają określony numer uruchomienia
`branch`	Artefakty z najnowszej kompilacji wykonanej 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 wykonanej w określonej gałęzi, która ma wszystkie określone tagi
Brak	Artefakty z najnowszej kompilacji we wszystkich gałęziach

Poniższa pipeline definicja zasobu używa branch właściwości i tags do oceny domyślnej wersji po wyzwoleniu potoku ręcznie lub zgodnie z harmonogramem. Po ręcznym wyzwoleniu potoku do uruchomienia MyCIAlias wersja artefaktów potoku jest najnowszą kompilacją wykonywaną w main gałęzi zawierającej Production tagi i .PrepProduction

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

Wyzwalacz uzupełniania 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 versionwłaściwości , branchi 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 jest wyzwalany za każdym razem, gdy potok zasobów pomyślnie ukończy przebieg oznaczony wszystkimi określonymi tagami.
`stages`	Nowy przebieg potoku jest wyzwalany za każdym razem, gdy potok zasobu pomyślnie wykona określony `stages`element .
`branches`, `tags`i `stages`	Nowy przebieg potoku jest wyzwalany za każdym razem, gdy uruchomienie potoku 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 wyzwalany żaden nowy przebieg potoku po pomyślnym zakończeniu przebiegu potoku zasobów.

Następujący potok jest uruchamiany za każdym razem, SmartHotel-CI gdy potok zasobów:

Uruchamia się w jednej z releases gałęzi lub gałęzi main
Jest oznakowany zarówno przy użyciu polecenia , jak Verified i Signed
Kończy zarówno etapy, jak 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 bieżącym uruchomieniem lub innym zasobem potoku.

Wszystkie artefakty z bieżącego potoku i wszystkich jego pipeline zasobów są automatycznie pobierane i udostępniane na początku każdego zadania wdrażania. To zachowanie można zastąpić, ustawiając downloadnonewartość , lub określając inny identyfikator zasobu potoku.

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

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

Właściwość opcjonalna artifact określa nazwy artefaktów. Jeśli nie zostanie określony, 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 przebiegu metadane zasobu potoku są dostępne dla wszystkich zadań jako wstępnie zdefiniowane zmienne. Te zmienne są dostępne tylko dla potoku 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 wstępnie 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, który generuje artefakty, możesz korzystać z artefaktów z builds zasobami. 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 version wartość domyślna build 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 w przypadku hostowanego serwera Jenkins tylko wtedy, gdy usługa Azure DevOps ma widok z serwerem Jenkins.

Zadanie downloadBuild

Artefakty build zasobów nie są automatycznie pobierane w zadaniach/zadaniach wdrażania. Aby korzystać z artefaktów z build zasobu w ramach zadań, należy jawnie 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 zdefiniowanego build przez środowisko uruchomieniowe. Artefakty z build zasobu są pobierane do elementu $(PIPELINE). WORKSPACE)/<build-identifier>/ folder.

downloadBuild W definicji należy określić zasób do pobrania artefaktów. Właściwość opcjonalna artifact określa artefakty do pobrania. Jeśli nie zostanie określony, 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 potok zawiera szablony w innym repozytorium lub chcesz użyć wyewidencjonowania wielu repozytoriów z repozytorium, które wymaga 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.repositoryies.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. Jest <Alias> to identyfikator, który podajesz zasób 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)"

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)"

Wyewidencjonuj słowo kluczowe dla repozytoriów

Repozytoria z repository zasobu 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, zobacz Sprawdzanie wielu repozytoriów w potoku.

Definicja zasobu kontenerów

Jeśli musisz korzystać z obrazów kontenerów w ramach potoków ciągłej integracji/ciągłego wdrażania, możesz użyć containers zasobów. 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 w ramach zadania lub użyć zasobu dla zadań kontenera. Jeśli potok wymaga obsługi co najmniej jednej usługi, musisz utworzyć kontenery usług i połączyć się z nimi. Za pomocą woluminów można udostępniać dane między usługami.

Jeśli musisz używać obrazów z rejestru platformy Docker w ramach potoku, możesz zdefiniować ogólny zasób kontenera. Żadne słowo kluczowe nie type jest wymagane. 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 usługi Azure Container Registry, możesz użyć typu zasobu acrkontenera pierwszej klasy . Tego typu zasobu można użyć w ramach zadań i włączyć wyzwalacze potoku automatycznego.

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ć acr typu zasobu, należy określić azureSubscriptionwartości , resourceGroupi repository dla rejestru kontenerów platformy Azure. Na przykład:

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

Uwaga

Połączenia usług korzystające z federacji tożsamości obciążenia nie są obsługiwane w programie azureSubscription.

Zmienne zasobów kontenera

Po zdefiniowaniu kontenera jako zasobu metadane obrazu kontenera są przekazywana 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 używać jako zasobów 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 elementów webhook

Uwaga

Elementy webhook zostały wydane w usłudze Azure DevOps Server 2020.1.

Możesz używać artefaktów i włączać automatyczne wyzwalacze za pomocą potoku, kontenera, kompilacji i zasobów pakietu. 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 elementów webhook i używać zdarzeń do wyzwalania 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, w których usługa Azure DevOps nie ma wglądu w proces, można skonfigurować elementy webhook w usłudze i automatycznie wyzwalać potoki.

Aby zasubskrybować zdarzenie elementu webhook, należy zdefiniować zasób elementu webhook w potoku i wskazać go na przychodzące połączenie usługi elementu webhook. Można również zdefiniować więcej filtrów dla zasobu elementu webhook na podstawie danych ładunku JSON, aby dostosować wyzwalacze dla każdego potoku.

Za każdym razem, gdy przychodzące połączenie usługi elementu webhook odbiera zdarzenie elementu webhook, nowe wyzwalacze uruchamiania dla wszystkich potoków subskrybowanych do zdarzenia elementu webhook. Dane ładunku JSON można używać w zadaniach jako zmiennych przy użyciu 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 elementu webhook:

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

Wyzwalacze elementu webhook

Aby skonfigurować wyzwalacze elementu webhook, należy najpierw skonfigurować element 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 przychodzące połączenie usługi elementu webhook. W przypadku tego typu połączenia z usługą należy zdefiniować następujące informacje:

Nazwa elementu webhook: taka sama jak element webhook utworzony w usłudze zewnętrznej.
Wpis tajny (opcjonalnie): służy do weryfikowania skrótu HMAC-SHA1 ładunku na potrzeby weryfikacji żądania przychodzącego. Jeśli podczas tworzenia elementu webhook użyto wpisu tajnego, musisz podać ten sam wpis tajny.
Nagłówek HTTP: nagłówek HTTP w żądaniu zawierający wartość skrótu HMAC-SHA1 ładunku na potrzeby 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 elementu webhook.

Aby wyzwolić potok przy użyciu elementu webhook, 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 elementu webhook może prowadzić do nieprawidłowego kodu YAML. Na przykład krok - script: echo ${{ parameters.WebHook.resource.message }} potoku ściąga cały komunikat JSON, który generuje nieprawidłowy kod YAML. Żaden potok wyzwolony za pośrednictwem tego elementu webhook nie jest uruchamiany, ponieważ wygenerowany kod YAML stał się nieprawidłowy.

Poniższy fragment kodu przedstawia inny przykład użycia filtrów elementó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 YAML ciągłego wdrażania usługa Azure Pipelines automatycznie ocenia domyślne wersje zasobów zdefiniowanych w potoku na podstawie podanych danych wejściowych. 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.

Selektor wersji zasobów umożliwia ręczne wybranie innej wersji podczas tworzenia przebiegu. Selektor wersji zasobów jest obsługiwany dla zasobów potoku, kompilacji, repozytorium, kontenera i pakietu.

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ć przebieg zakończony powodzeniem, niepowodzeniem lub w toku. Ta elastyczność zapewnia możliwość uruchomienia potoku ciągłego wdrażania, jeśli masz pewność, że przebieg wygenerował wszystkie potrzebne artefakty. Nie musisz czekać na ukończenie przebiegu ciągłej integracji ani ponownie uruchomić go z powodu niepowiązanego niepowodzenia etapu.

Aby użyć selektora wersji zasobów, w okienku Uruchamianie potoku wybierz pozycję Zasoby, a następnie wybierz zasób i wybierz 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ę przebiegu do wybrania.

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 potoki, które mogą uzyskiwać dostęp do swoich zasobów. Istnieje kilka sposobów autoryzowania potoku YAML do korzystania z zasobów.

Użyj środowiska administracyjnego zasobów, aby autoryzować wszystkie potoki w celu uzyskania dostępu 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

Sprawdzanie zatwierdzenia i szablony umożliwiają ręczne kontrolowanie, kiedy zasób jest uruchamiany. W przypadku sprawdzania zatwierdzenia wymaganego szablonu można wymagać, aby dowolny potok przy użyciu zasobu lub środowiska wykraczał poza określony szablon 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 na temat rozszerzania zabezpieczeń potoku za pomocą szablonów, zobacz Używanie szablonów do zabezpieczeń.

Identyfikowalność

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

Możliwość śledzenia potoku

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 używane artefakty.
Zatwierdzenia skojarzone z każdym zasobem.
Elementy robocze skojarzone z każdym zasobem.

Śledzenie środowiska

Za każdym razem, gdy potok jest wdrażany w środowisku, można wyświetlić listę zasobów, które są używane. Widok zawiera zasoby używane w ramach zadań wdrażania oraz skojarzone z nimi zatwierdzenia i elementy robocze.

Zrzut ekranu przedstawiający zatwierdzenia w środowisku.

Skojarzone potoki ciągłego wdrażania w potokach ciągłej integracji

Aby zapewnić kompleksową możliwość śledzenia, możesz śledzić, które potoki ciągłego wdrażania używają określonego potoku ciągłej pipelines integracji za pośrednictwem zasobu. Jeśli inne potoki korzystają z potoku ciągłej integracji, w widoku Uruchamiania zostanie wyświetlona karta Skojarzone potoki. Widok przedstawia wszystkie uruchomienia potoku YAML ciągłego wdrażania, które używają potoku ciągłej integracji i artefaktów z niego.

Zrzut ekranu przedstawiający informacje o potokach ciągłej integracji 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 są zgodne.

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

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?

pipelines Użycie zasobu to sposób używania artefaktów z potoku ciągłej integracji, a także konfigurowania zautomatyzowanych wyzwalaczy. Zasób zapewnia pełny wgląd w proces, wyświetlając używaną wersję, artefakty, zatwierdzenia 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 zastąpić zachowanie pobierania 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 usługi Docker Hub, dlatego należy skonfigurować klasyczny potok wydania.

Utwórz nowe połączenie usługi Docker Hub.
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.
Wybierz wyzwalacz i przełącz wyzwalacz ciągłego wdrażania na wartość Włącz. Każde wypychanie platformy Docker wykonywane do wybranego repozytorium tworzy wydanie.
Utwórz nowy etap i zadanie. Dodaj dwa zadania: logowanie do platformy Docker i powłokę Bash.
- Zadanie platformy login Docker zawiera akcję i loguje cię do usługi Docker Hub.
- Zadanie powłoki Bash uruchamia polecenie docker pull <hub-user>/<repo-name>[:<tag>].

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

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

Odwołuj się do połączenia z usługą i nadaj nazwę elementowi webhook w webhooks sekcji .

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

Uruchom swój potok. Element webhook jest tworzony na platformie Azure jako zadanie rozproszone dla organizacji.
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ź kodu stanu 200, element webhook jest gotowy do użycia przez potok.

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:

Wybierz pozycję Edytuj na stronie potoku.
Z menu Więcej akcji wybierz pozycję Wyzwalacze.
Wybierz kartę YAML , a następnie wybierz pozycję Pobierz źródła.
W obszarze Gałąź domyślna dla kompilacji ręcznych i zaplanowanych zaktualizuj gałąź funkcji.
Wybierz pozycję Zapisz i kolejkę.
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>. Powinna zostać wyświetlona odpowiedź z kodem stanu 200.

Informacje o zasobach dla usługi Azure Pipelines
Definiowanie zmiennych
Dodawanie i używanie grup zmiennych
Create and target an environment (Tworzenie środowiska i wyznaczanie go jako miejsce docelowe)
Korzystanie z edytora potoków YAML
Dokumentacja schematu YAML

Udostępnij za pośrednictwem

Zasoby w potokach YAML

Schemat zasobów

Definicja zasobu potoków

Przykładowe definicje zasobów potoku

Ocena wersji artefaktu potoków

Wyzwalacz ręczny lub zaplanowany

Wyzwalacz uzupełniania potoku zasobów

Pobieranie artefaktu potoku

Zmienne zasobów potoku

Kompiluje definicję zasobu

Zadanie downloadBuild

Definicja zasobu repozytorium

Typy zasobów repozytorium

Zmienne zasobów repozytorium

Wyewidencjonuj słowo kluczowe dla repozytoriów

Definicja zasobu kontenerów

Typ zasobu usługi Azure Container Registry

Zmienne zasobów kontenera

Definicja zasobu pakietów

Definicja zasobu elementów webhook

Wyzwalacze elementu webhook

Selektor wersji ręcznej dla zasobów

Autoryzacja zasobów w potokach YAML

Sprawdzanie zatwierdzenia zasobów

Identyfikowalność

Możliwość śledzenia potoku

Śledzenie środowiska

Skojarzone potoki ciągłego wdrażania w potokach ciągłej integracji

Problemy z wyzwalaczem zasobów

Często zadawane pytania

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

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

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

Opinia

Opinia

Dodatkowe zasoby

Udostępnij za pośrednictwem

Zasoby w potokach YAML

Schemat zasobów

Definicja zasobu potoków

Przykładowe definicje zasobów potoku

Ocena wersji artefaktu potoków

Wyzwalacz ręczny lub zaplanowany

Wyzwalacz uzupełniania potoku zasobów

Pobieranie artefaktu potoku

Zmienne zasobów potoku

Kompiluje definicję zasobu

Zadanie downloadBuild

Definicja zasobu repozytorium

Typy zasobów repozytorium

Zmienne zasobów repozytorium

Wyewidencjonuj słowo kluczowe dla repozytoriów

Definicja zasobu kontenerów

Typ zasobu usługi Azure Container Registry

Zmienne zasobów kontenera

Definicja zasobu pakietów

Definicja zasobu elementów webhook

Wyzwalacze elementu webhook

Selektor wersji ręcznej dla zasobów

Autoryzacja zasobów w potokach YAML

Sprawdzanie zatwierdzenia zasobów

Identyfikowalność

Możliwość śledzenia potoku

Śledzenie środowiska

Skojarzone potoki ciągłego wdrażania w potokach ciągłej integracji

Problemy z wyzwalaczem zasobów

Często zadawane pytania

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

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

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

Powiązana zawartość

Opinia

Opinia

Dodatkowe zasoby