Zasoby w potokach YAML

Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022

W tym artykule omówiono zasoby dla ciągów YAML. Zasób to wszystko, czego używa potok, który istnieje poza tym potokiem. Zasoby w potokach YAML mogą być innymi potokami, kompilacjami, kontenerami, pakietami, repozytoriami lub elementami webhook.

Po zdefiniowaniu zasobu można z niego korzystać w dowolnym miejscu w potoku. Aby uzyskać więcej informacji i przykładów, zobacz Definicje zasobów.

resources:
  pipelines:
  - pipeline: resources1
    source: otherPipeline

steps:
- download: resources1
  artifact: artifact1.txt

Stan zasobu umożliwia automatyczne wyzwalanie potoków przez ustawienie trigger właściwości w definicji zasobu. Następnie potok resources.triggeringAlias i resources.triggeringCategory zmienne są ustawiane na nazwę zasobu i kategorię. Te zmienne są puste, chyba że zmienna jest ustawiona Build.Reason na ResourceTriggerwartość .

Zasoby umożliwiają pełne śledzenie usług używanych przez potok, w tym wersję, artefakty, skojarzone zatwierdzenia i elementy robocze. Jeśli subskrybujesz wyzwalanie zdarzeń w zasobach, możesz w pełni zautomatyzować przepływy pracy metodyki DevOps.

Autoryzacja zasobów

Zasoby muszą być autoryzowane do użycia 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 ustawień administracyjnych zasobu, aby udzielić uprawnień dostępu do wszystkich potoków. Na przykład można zarządzać bezpiecznymi plikami i grupami zmiennych na stronieBiblioteka> oraz pulami agentów i połączeniami usług wpotokach> projektu. Ta autoryzacja jest wygodna dla zasobów, których nie trzeba ograniczać, takich jak zasoby testowe.

• Upewnij się, że masz co najmniej rolę użytkownika w rolach zabezpieczeń puli agentów dla projektu. Tworzone potoki YAML są automatycznie autoryzowane do korzystania z zasobów, w których masz rolę użytkownika .

• Jeśli dodasz definicję zasobu do potoku YAML, ale 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, upewnij się, że masz co najmniej rolę użytkownika w zasobie. Następnie możesz wybrać opcję autoryzowania zasobów w kompilacji, która zakończyła się niepowodzeniem. Po autoryzowanym zasobie możesz rozpocząć nową kompilację.

Sprawdzanie zatwierdzenia zasobów

Możesz użyć kontroli zatwierdzania i szablonów, aby ręcznie kontrolować użycie zasobów. Korzystając z wymaganego sprawdzania zatwierdzenia szablonu, możesz wymagać dowolnego potoku, który używa określonego zasobu lub środowiska do rozszerzenia z określonego szablonu YAML.

Ustawienie wymaganego zatwierdzenia szablonu zwiększa bezpieczeństwo, zapewniając, że zasób jest używany tylko w określonych warunkach. Aby uzyskać więcej informacji, zobacz Używanie szablonów do zabezpieczeń.

Selektor wersji zasobów ręcznych

Usługa Azure Pipelines ocenia domyślne wersje zasobów na podstawie ich definicji zasobów. W przypadku zaplanowanych przebiegów lub przebiegów ręcznych, jeśli nie wybierzesz ręcznie przebiegu, usługa Azure Pipelines uwzględnia tylko pomyślne ukończenie przebiegów ciągłej integracji w celu oceny domyślnych wersji zasobów.

Możesz użyć selektora wersji zasobów ręcznych, aby wybrać różne wersje zasobów podczas ręcznego wyzwalania potoku ciągłego wdrażania YAML (CD). Selektor wersji dla zasobów jest obsługiwany w przypadku zasobów związanych z potokiem, kompilacją, repozytorium, kontenerem oraz pakietem.

W przypadku pipeline zasobów selektor wersji ręcznej umożliwia wyświetlenie wszystkich dostępnych przebiegów we wszystkich gałęziach, przeszukanie przebiegów na podstawie numeru potoku lub gałęzi i wybranie przebiegu, które zakończyło się powodzeniem, niepowodzeniem lub w toku.

Nie musisz czekać na ukończenie przebiegu ciągłej integracji ani uruchomić go ponownie z powodu niepowiązanego błędu, zanim będzie można uruchomić potok ciągłego wdrażania. Masz elastyczność wyboru dowolnego przebiegu, który znasz, wygenerował potrzebne artefakty.

Aby użyć selektora wersji zasobów, wybierz pozycję Zasoby w okienku Potok uruchamiania , wybierz zasób i wybierz określoną wersję z listy dostępnych wersji. W przypadku zasobów, w których nie można pobrać dostępnych wersji, takich jak pakiety GitHub, możesz wprowadzić żądaną wersję w polu tekstowym.

Definicje zasobów

Zasoby potoku YAML mogą być następujące:

• Inne potoki
• Buduje
• Pojemniki
• Pakiety
• Repozytoria lub
• Elementy webhook.

Poniższe sekcje zawierają definicje i przykłady kategorii zasobów potoku YAML. Aby uzyskać pełne informacje o schemacie, zobacz definicję zasobów w dokumentacji schematu YAML dla usługi Azure Pipelines.

Zasób potoków

Zasoby ciągłej integracji pipeline można używać jako wyzwalaczy dla przepływów pracy ciągłego wdrażania. Możesz również odwoływać się do pipeline zasobów z potoku, aby pobrać artefakty lub użyć zmiennych zasobów potoku. Tylko Azure Pipelines może używać zasobu pipelines.

pipelines W definicji zasobu:

• pipeline to unikatowa nazwa używana do odwołowania się do zasobów potoku.
• source to nazwa potoku, który wygenerował artefakty potoku.

Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.pipelines.pipeline .

Przykładowe definicje zasobów pipeline’u

Poniższa przykładowa definicja zasobu używa artefaktów z potoku w ramach tego samego projektu usługi Azure DevOps.

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

Aby określić potok z innego projektu, uwzględnij project nazwę w definicji zasobu. W poniższym przykładzie użyto branch również funkcji rozpoznawania wersji domyślnej, 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: otherDevOpsProject
    source: SmartHotel-CI
    branch: releases/M142

Ocena wersji zasobu

Usługa Azure Pipelines ocenia domyślne wersje zasobów na podstawie ich definicji zasobów. Domyślne wersje artefaktów zasobów potoku zależą od tego, czy potok działa ręcznie, czy zgodnie z harmonogramem, czy też wyzwalacze na podstawie wyniku uruchomienia zasobu.

W przypadku ręcznego lub zaplanowanego przebiegu potoku wartości versionwłaściwości , branchi tags w pipeline definicji zasobu definiują wersje artefaktów. Dane branch wejściowe nie mogą mieć symboli wieloznacznych, a tags właściwości używają AND operatora .

W przypadku zaplanowanych przebiegów lub przebiegów ręcznych, jeśli nie używasz selektora wersji, usługa Azure Pipelines uwzględnia tylko pomyślne ukończenie przebiegów ciągłej integracji podczas oceniania domyślnych wersji zasobów. W przypadku przebiegów ręcznych można zastąpić zdefiniowane wersje przy użyciu selektora wersji ręcznej.

W poniższej tabeli wymieniono pipeline właściwości definicji zasobów i określone wersje artefaktów.

Poniższa pipeline definicja zasobu używa branch właściwości i tags do oceny wersji domyślnej, gdy potok jest zaplanowany lub wyzwalany ręcznie. Wersja myCIAlias artefaktów to najnowsze uruchomienie kompilacji w main gałęzi zawierającej Production tagi i PreProduction .

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

Wyzwalacze zasobów potoku

W przypadku przebiegów potoku, które wyzwalają wynik uruchomienia zasobu, trigger ustawienia właściwości w definicji zasobu określają domyślne wersje artefaktów zasobów. Aby użyć pipeline zasobu jako wyzwalacza do uruchomienia bieżącego potoku, musisz ustawić trigger właściwość . Jeśli nie dołączysz trigger właściwości, przebiegi zasobów nie wyzwalają bieżących przebiegów potoku.

Gdy potok jest wyzwalany na trigger podstawie wartości w pipeline definicji zasobu, wartości ogólnej definicji versionzasobu , branchi właściwości tags są ignorowane. Właściwości trigger określają wersje artefaktów.

W poniższej tabeli opisano, jak trigger właściwości wpływają na zachowanie wyzwalacza.

W poniższym przykładzie przedstawiono definicję zasobów potoków z prostą triggerdefinicją .

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

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

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    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. Wyzwalacz stages użyj AND operatora . Potok ciągłego wdrażania jest wyzwalany po pomyślnym zakończeniu wszystkich wymienionych etapów.

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

W poniższym przykładzie użyto tags filtrów do domyślnej oceny wersji i wyzwalacza. Tagi trigger używają AND operatora . Zestaw tags w pipeline definicjach zasobów różni się od tagów ustawionych w gałęziach w repozytorium Git.

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

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

• Uruchamia się w jednej z releases gałęzi lub gałęzi main .
• Jest oznaczony tagiem i VerifiedSigned.
• Kończy zarówno etapy, jak Production i PreProduction .

resources:
  pipelines:
  - pipeline: SmartHotel
    project: otherDevOpsProject
    source: SmartHotel-CI
    trigger:
      branches:
        include:
        - releases/*
        - main
        exclude:
        - topic/*
      tags: 
      - Verified
      - Signed
      stages:
      - Production
      - PreProduction

Pobieranie artefaktu linii przetwarzania

Możesz użyć download kroku w potoku YAML, aby pobrać artefakty skojarzone z bieżącym uruchomieniem lub innym pipeline zasobem.

Artefakty są pobierane automatycznie tylko w zadaniach wdrażania. Wszystkie artefakty z bieżącego potoku i wszystkie jego pipeline zasoby są automatycznie pobierane i są dostępne na początku każdego zadania wdrożenia. To zachowanie można zastąpić, ustawiając downloadnonewartość , lub określając inny pipeline identyfikator zasobu.

W zwykłym zadaniu kompilacji artefakty nie są pobierane automatycznie. W razie potrzeby użyj download jawnie.

download W kroku właściwość opcjonalna artifact określa nazwy artefaktów. Jeśli nie zostanie określony, wszystkie dostępne artefakty zostaną pobrane.

Właściwość opcjonalna patterns definiuje wzorce reprezentujące pliki do pobrania. Aby uzyskać pełne informacje o schemacie, zobacz definicję steps.download .

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

Artefakty pobrane z pipeline zasobu do elementu $(PIPELINE). WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folder. Aby uzyskać więcej informacji, zobacz Publikowanie i pobieranie artefaktów pipeline. Aby uzyskać alternatywny sposób pobierania artefaktów z potoku, zobacz Pobieranie artefaktów.

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 zasób

Jeśli masz system kompilacji ciągłej integracji, który generuje artefakty, możesz wykorzystać artefakty z builds zasobami.

Kategoria builds jest rozszerzalna. Zasób build może pochodzić z dowolnego zewnętrznego systemu ciągłej integracji, takiego jak Jenkins, TeamCity lub CircleCI. Możesz użyć builds polecenia , aby napisać rozszerzenie, aby korzystać z artefaktów z usługi kompilacji lub wprowadzić nowy typ usługi.

W definicji build wartość domyślna version to najnowsza pomyślna kompilacja. W razie potrzeby należy jawnie ustawić trigger . Aby uzyskać pełne informacje o schemacie, zobacz definicję resources.builds.build .

W poniższym przykładzie serwer Jenkins jest typem zasobu.

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

Zadanie downloadBuild

Artefakty build zasobów nie są automatycznie pobierane do zadań/zadań 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ć.

Zadanie downloadBuild automatycznie rozpoznaje odpowiednie zadanie pobierania dla typu zasobu zdefiniowanego build przez środowisko uruchomieniowe. Artefakty pobrane z build zasobu do elementu $(PIPELINE). WORKSPACE)/<build-identifier>/ folder.

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 określony, wszystkie artefakty skojarzone z pobieraniem zasobów.

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. Poniższy przykład 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 .

Zasób repozytoriów

Użyj słowa kluczowego repository , aby poinformować system o repozytoriach zewnętrznych, jeśli:

• Potok zawiera szablony w innym repozytorium.
• Chcesz użyć wyewidencjonowania wielu repozytoriów z repozytorium, które wymaga połączenia z usługą.

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 gittypy repozytoriów , githubgithubenterprise, i 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.

W poniższej repository tabeli opisano typy zasobów:

Zmienne zasobów repozytorium

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

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

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. Słowo kluczowe służy checkout do pobierania repozytorium zdefiniowanego w zasobie repository . Aby uzyskać więcej informacji, zapoznaj się z artykułem Korzystanie z wielu repozytoriów w potoku. Aby uzyskać pełne informacje o schemacie, zobacz definicję steps.checkout .

Zasób kontenerów

Zasoby umożliwiają korzystanie z containers obrazów kontenerów w potokach ciągłej integracji/ciągłego wdrażania. 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 zadań lub użyć go w zadaniach kontenera. Jeśli potok wymaga obsługi co najmniej jednej usługi, musisz również 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, możesz zdefiniować ogólny zasób kontenera bez użycia słowa kluczowego type . Na przykład:

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

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

Typ zasobu usługi Azure Container Registry

Aby korzystać z obrazów Azure Container Registry, możesz użyć pierwszoklasowego zasobu kontenerowego acr. Tego typu zasobu można użyć w zadaniach i włączyć wyzwalacze potoku automatycznego.

Aby korzystać 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* 

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 typu zasobu kontenera acr .

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)

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

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: myWebhookResource
      connection: myWebHookConnection

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

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}}

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

Identyfikowalność

Usługa Azure Pipelines zapewnia pełną możliwość śledzenia dowolnego zasobu używanego na poziomie zadania potoku lub wdrożenia. Usługa Azure Pipelines zawiera następujące informacje dotyczące każdego uruchomienia potoku korzystającego z zasobów:

• Jeśli zasób wyzwolił potok, zasób, który wyzwolił potok.
• Wersje zasobów i używane artefakty.
• Zatwierdzenia skojarzone z każdym zasobem.
• Elementy robocze skojarzone z każdym zasobem.

Informacje dotyczące skojarzonego potoku ciągłego wdrażania dla potoków 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 używają potoku ciągłej integracji, w widoku Uruchamiania zostanie wyświetlona karta Skojarzone potoki. 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.

Śledzenie środowiska

Po wdrożeniu potoku w środowisku można wyświetlić listę zasobów, z których korzysta, oraz skojarzonych z nimi zatwierdzeń i elementów roboczych.

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 potokowego, związane z nim artefakty są automatycznie pobierane w zadaniach wdrożeniowych.

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 Download Pipeline Artifacts nie zapewnia możliwości śledzenia ani wyzwalaczy, ale czasami warto użyć 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 budowie 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.

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 POST API z prawidłowym kodem JSON w treści do https://dev.azure.com/<organization>/_apis/public/distributedtask/webhooks/<webhook-name>?api-version=<apiversion>. Powinieneś teraz otrzymać odpowiedź z kodem stanu 200.

Dlaczego mój wyzwalacz zasobu nie zadziałał?

Wyzwalacze zasobów mogą się nie wykonać, ponieważ:

• Źródło podanego połączenia z usługą jest nieprawidłowe.
• Wyzwalacz nie jest skonfigurowany lub w wyzwalaczu występują błędy składni.
• 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 wyzwalaczem nie są dostępne dla zasobów repozytorium.

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

Powiązana zawartość

• Informacje o zasobach dla usługi Azure Pipelines
• Definiowanie zmiennych
• Dodawanie i używanie grup zmiennych
• Utwórz i wyceluj środowisko
• Korzystanie z edytora potoków YAML
• Dokumentacja schematu YAML