Definiowanie zasobów w języku YAML

  • Artykuł

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

Zasoby w języku YAML reprezentują źródła potoków, kompilacji, repozytoriów, kontenerów, pakietów i elementów webhook. Zasoby zapewniają również pełną możliwość śledzenia usług używanych w potoku, w tym wersji, artefaktów, skojarzonych zatwierdzeń i elementów roboczych. Po zdefiniowaniu zasobu można go używać w dowolnym miejscu potoku. Możesz również w pełni zautomatyzować przepływ pracy metodyki DevOps, subskrybując wyzwalanie zdarzeń w zasobach.

Aby uzyskać więcej informacji, zobacz About resources and the resources YAML schema definition (Informacje o zasobach i definicji schematu YAML zasobów).

Schemat

resources:
  pipelines: [ pipeline ]  
  builds: [ build ]
  repositories: [ repository ]
  containers: [ container ]
  packages: [ package ]
  webhooks: [ webhook ]

Zmienne

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

resources.triggeringAlias
resources.triggeringCategory

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

Definiowanie pipelines zasobu

Jeśli masz potok, który generuje artefakty, możesz użyć artefaktów, definiując pipelines zasób. pipelines to dedykowany zasób tylko dla usługi Azure Pipelines. Wyzwalacze można również ustawić dla zasobu potoku dla przepływów pracy ciągłego wdrażania.

W definicji zasobu jest unikatową wartością, pipeline której można użyć do późniejszego odwołowania się do zasobu potoku. source to nazwa potoku, który generuje artefakt. Użyj etykiety zdefiniowanej przez pipeline , aby odwołać 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 potoków, zobacz zadania w artykule Pipeline Artifacts (Artefakty potoku).

resources:        # types: pipelines | builds | repositories | containers | packages
  pipelines:
  - pipeline: string  # identifier for the resource used in pipeline resource variables
    project: string # project for the source; optional for current project
    source: string  # name of the pipeline that produces an artifact. If it is in a different pipelines folder, it needs to be the full path, e.g. MyTeam/MyPipeline
    version: string  # the pipeline run number (Build.BuildNumber) to pick the artifact, defaults to latest pipeline successful run across all stages; Used only for manual or scheduled triggers
    branch: string  # branch to pick the artifact, optional; defaults to all branches; Used only for manual or scheduled triggers
    tags: [ string ] # list of tags required on the pipeline to pickup default artifacts, optional; Used only for manual or scheduled triggers
    trigger:     # triggers aren't enabled by default unless you add trigger section to the resource
      branches:  # branch conditions to filter the events, optional; Defaults to all branches.
        include: [ string ]  # branches to consider for the trigger events, optional; Defaults to all branches.
        exclude: [ string ]  # branches to discard the trigger events, optional; Defaults to none.
      tags: [ string ]  # list of tags to evaluate for trigger event, optional
      stages: [ string ] # list of stages to evaluate for trigger event, optional

Ważne

Jeśli zdefiniujesz wyzwalacz zasobu, jeśli jego zasób potoku pochodzi z tego samego repozytorium (np. własnego) co bieżący potok, wyzwalanie jest zgodne z tą samą gałęzią i zatwierdzeniem, na którym jest zgłaszane zdarzenie. Jeśli jednak zasób potoku pochodzi z innego repozytorium, bieżący potok jest wyzwalany w domyślnej gałęzi repozytorium samodzielnego.

Ocena wersji artefaktu

Wersja artefaktów potoku zasobów zależy od sposobu wyzwalania potoku.

Jeśli potok jest uruchamiany, ponieważ został on wyzwolony ręcznie lub z powodu zaplanowanego uruchomienia, wersja artefaktu jest definiowana przez wartości versionwłaściwości , branchi tags .

Określone właściwości Wersja artefaktu
version Artefakty z kompilacji o określonym numerze uruchomienia
branch Artefakty z najnowszej kompilacji wykonanej w określonej gałęzi
tags Listy Artefakty z najnowszej kompilacji zawierającej wszystkie określone tagi
branch i tags lista Artefakty z najnowszej kompilacji wykonanej w określonej gałęzi i zawierające wszystkie określone tagi
Brak Artefakty z najnowszej kompilacji we wszystkich gałęziach

Spójrzmy na przykład. Załóżmy, że potok zawiera następującą definicję zasobu.

resources:
  pipelines:
  - pipeline: MyCIAlias
    project: Fabrikam
    source: Farbrikam-CI
    branch: main      ### This branch input cannot have wild cards. It is used for evaluating default version when pipeline is triggered manually or scheduled.
    tags:               ### These tags are used for resolving default version when the pipeline is triggered manually or scheduled
    - Production        ### Tags are AND'ed
    - PreProduction

Po ręcznym wyzwoleniu potoku do uruchomienia wersja artefaktów MyCIAlias potoku jest jedną z najnowszych kompilacji wykonanych w main gałęzi i z tagami Production i PrepProduction .

Gdy potok zostanie wyzwolony z powodu ukończenia jednego z jego potoków zasobów, wersja artefaktów jest jednym z potoków wyzwalających. Wartości versionwłaściwości , branchi tags są ignorowane.

Określone wyzwalacze Wynik
branches Nowe uruchomienie bieżącego potoku jest wyzwalane za każdym razem, gdy potok zasobów pomyślnie ukończy przebieg w gałęziach include
tags Nowe uruchomienie bieżącego potoku jest wyzwalane za każdym razem, gdy potok zasobów pomyślnie ukończy przebieg oznaczony wszystkimi określonymi tagami
stages Nowe uruchomienie bieżącego potoku jest wyzwalane za każdym razem, gdy potok zasobów pomyślnie wykona określony stages
branches, tagsi stages Nowe uruchomienie bieżącego potoku jest wyzwalane za każdym razem, gdy uruchomienie potoku zasobów spełnia wszystkie warunki gałęzi, tagów i etapów
trigger: true Nowe uruchomienie bieżącego potoku jest wyzwalane za każdym razem, gdy potok zasobu pomyślnie ukończy przebieg
Nic Po pomyślnym ukończeniu przebiegu potoku zasobu nie jest wyzwalane żadne nowe uruchomienie bieżącego potoku

Spójrzmy na przykład. Załóżmy, że potok zawiera następującą definicję zasobu.

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

Potok będzie uruchamiany za każdym razem, gdy SmartHotel-CI potok jest uruchamiany w jednej z releases gałęzi lub main gałęzi, jest oznaczony tagiem i Verified , i zakończył zarówno Production etapy, jak i SignedPreProduction .

download dla potoków

Wszystkie artefakty z bieżącego potoku i ze wszystkich pipeline zasobów są automatycznie pobierane i udostępniane na początku każdego deployment zadania. To zachowanie można zastąpić. Aby uzyskać więcej informacji, zobacz Pipeline Artifacts (Artefakty potoku). Zwykłe artefakty "job" nie są pobierane automatycznie. W razie potrzeby użyj download jawnie.

steps:
- download: [ current | pipeline resource identifier | none ] # disable automatic download if "none"
  artifact: string ## artifact name, optional; downloads all the available artifacts if not specified
  patterns: string # patterns representing files to include; optional

Artefakty z pipeline zasobu są pobierane do $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> folderu.

Zmienne zasobów potoku

W każdym przebiegu metadane zasobu potoku są dostępne dla wszystkich zadań w postaci wstępnie zdefiniowanych zmiennych. Jest <Alias> to identyfikator podany dla zasobu potoku. Zmienne zasobów potoku są dostępne tylko w czasie wykonywania.

Aby dowiedzieć się więcej na temat składni zmiennych, zobacz Definiowanie zmiennych.

resources.pipeline.<Alias>.projectID
resources.pipeline.<Alias>.pipelineName
resources.pipeline.<Alias>.pipelineID
resources.pipeline.<Alias>.runName
resources.pipeline.<Alias>.runID
resources.pipeline.<Alias>.runURI
resources.pipeline.<Alias>.sourceBranch
resources.pipeline.<Alias>.sourceCommit
resources.pipeline.<Alias>.sourceProvider
resources.pipeline.<Alias>.requestedFor
resources.pipeline.<Alias>.requestedForID

Aby uzyskać więcej informacji, zobacz Pipeline resource metadata as predefined variables (Metadane zasobów potoku jako wstępnie zdefiniowane zmienne).

Definiowanie builds zasobu

Jeśli masz zewnętrzny system kompilacji ciągłej integracji, który generuje artefakty, możesz używać artefaktów z zasobem builds . Zasób builds może być dowolnymi zewnętrznymi systemami ciągłej integracji, takimi jak Jenkins, TeamCity, CircleCI itd.

resources:        # types: pipelines | builds | repositories | containers | packages
  builds:
  - build: string   # identifier for the build resource
    type: string   # the type of your build service like Jenkins, circleCI etc.
    connection: string   # service connection for your build service.
    source: string   # source definition of the build
    version: string   # the build number to pick the artifact, defaults to Latest successful build
    trigger: boolean    # Triggers aren't enabled by default and should be explicitly set

builds jest rozszerzalną kategorią. Możesz napisać rozszerzenie do korzystania z artefaktów z usługi kompilacji i wprowadzić nowy typ usługi w ramach programu builds. Usługa Jenkins jest typem zasobu w systemie builds.

Ważne

Wyzwalacze są obsługiwane tylko w przypadku hostowanego serwera Jenkins, gdzie usługa Azure DevOps ma widok z serwerem Jenkins.

downloadBuild zadanie kompilacji

Artefakty z build zasobu można używać w ramach zadań przy użyciu downloadBuild zadania. Na podstawie typu zdefiniowanego build zasobu to zadanie automatycznie rozwiązuje odpowiednie zadanie pobierania usługi w czasie wykonywania.

Artefakty z build zasobu są pobierane do $(PIPELINE.WORKSPACE)/<build-identifier>/ folderu.

Ważne

build artefakty zasobów nie są automatycznie pobierane w zadaniach/zadaniach wdrażania. Musisz jawnie dodać downloadBuild zadanie do korzystania z artefaktów.

- downloadBuild: string # identifier for the resource from which to download artifacts
  artifact: string # artifact to download; if left blank, downloads all artifacts associated with the resource provided
  patterns: string | [ string ] # a minimatch path or list of [minimatch paths](tasks/file-matching-patterns.md) to download; if blank, the entire artifact is downloaded

Definiowanie repositories zasobu

Jeśli potok zawiera szablony w innym repozytorium lub jeśli chcesz użyć wyewidencjonowania z repozytorium, które wymaga połączenia z usługą, musisz poinformować system o tym repozytorium. Słowo repository kluczowe umożliwia określenie repozytorium zewnętrznego.

resources:
    repositories:
    - repository: string # Required as first property. Alias for the repository.
      endpoint: string # ID of the service endpoint connecting to this repository.
      trigger: none | trigger | [ string ] # CI trigger for this repository, no CI trigger if skipped (only works for Azure Repos).
      name: string # repository name (format depends on 'type'; does not accept variables).
      ref: string # ref name to checkout; defaults to 'refs/heads/main'. The branch checked out by default whenever the resource trigger fires.
      type: string # Type of repository: git, github, githubenterprise, and bitbucket.

Typ

Potoki obsługują następujące wartości dla typu repozytorium: git, , githubgithubenterprisei bitbucket. Typ git odnosi się do repozytoriów Git usługi Azure Repos.

Określony typ Wynik Przykład
type: git Wartość name odnosi się do innego repozytorium w tym samym projekcie. name: otherRepo Aby odwołać się do repozytorium w innym projekcie w tej samej organizacji, prefiks nazwy o nazwie tego projektu. Może to być na przykład name: OtherProject/otherRepo.
type: github Wartość name jest pełną nazwą repozytorium GitHub i zawiera użytkownika lub organizację. name: Microsoft/vscode
type: githubenterprise wartość name jest pełną nazwą repozytorium GitHub Enterprise i zawiera użytkownika lub organizację. name: Microsoft/vscode
type: bitbucket Wartość name jest pełną nazwą repozytorium Bitbucket Cloud i zawiera użytkownika lub organizację. name: MyBitbucket/vscode

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.

Zmienne

W każdym przebiegu metadane zasobu repozytorium są dostępne dla wszystkich zadań w postaci zmiennych środowiska uruchomieniowego. Jest <Alias> to identyfikator, który został podany dla zasobu repozytorium.

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

Zmienne

W każdym przebiegu metadane zasobu repozytorium są dostępne dla wszystkich zadań w postaci zmiennych środowiska uruchomieniowego. Jest <Alias> to identyfikator, który został podany dla zasobu 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

Użyj checkout polecenia , aby korzystać z repozytorium

Użyj słowa kluczowego, aby korzystać z checkout repozytoriów zdefiniowanych repository jako część zasobu.

Schemat

steps:
- checkout: string # Required as first property. Configures checkout for the specified repository.
  clean: string # If true, run git clean -ffdx followed by git reset --hard HEAD before fetching.
  fetchDepth: string # Depth of Git graph to fetch.
  fetchTags: string # Set to 'true' to sync tags when fetching the repo, or 'false' to not sync tags. See remarks for the default behavior.
  lfs: string # Set to 'true' to download Git-LFS files. Default is not to download them.
  persistCredentials: string # Set to 'true' to leave the OAuth token in the Git config after the initial fetch. The default is not to leave it.
  submodules: string # Set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules. Default is not to fetch submodules.
  path: string # Where to put the repository. The default is $(Build.SourcesDirectory).
  condition: string # Evaluate this condition expression to determine whether to run this task.
  continueOnError: boolean # Continue running even on failure?
  displayName: string # Human-readable name for the task.
  target: string | target # Environment in which to run this task.
  enabled: boolean # Run this task when the job runs?
  env: # Variables to map into the process's environment.
    string: string # Name/value pairs
  name: string # ID of the step.
  timeoutInMinutes: string # Time to wait for this task to complete before the server kills it.
  retryCountOnTaskFailure: string # Number of retries if the task fails.

Repozytoria z repository zasobu nie są automatycznie synchronizowane w zadaniach. Służy checkout do pobierania repozytoriów w ramach zadań.

Aby uzyskać więcej informacji, zobacz Sprawdzanie wielu repozytoriów w potoku.

Definiowanie containers zasobu

Jeśli musisz użyć obrazu kontenera w ramach potoku ciągłej integracji/ciągłego dostarczania (CI/CD), możesz go osiągnąć przy użyciu polecenia containers. Zasób kontenera może być publicznym lub prywatnym rejestrem platformy Docker lub usługą Azure Container Registry.

Jeśli musisz używać obrazów z rejestru platformy Docker w ramach potoku, możesz zdefiniować ogólny zasób kontenera (nie type jest wymagane słowo kluczowe).

resources:
  containers:
  - container: string  # identifier (A-Z, a-z, 0-9, and underscore)
    image: string  # container image name
    options: string  # arguments to pass to container at startup
    endpoint: string  # reference to a service connection for the private registry
    env: { string: string }  # list of environment variables to add
    ports: [ string ] # ports to expose on the container
    volumes: [ string ] # volumes to mount on the container
    mapDockerSocket: bool # whether to map in the Docker daemon socket; defaults to true
    mountReadOnly:  # volumes to mount read-only - all default to false
      externals: boolean  # components required to talk to the agent
      tasks: boolean  # tasks required by the job
      tools: boolean  # installable tools like Python and Ruby
      work: boolean # the work directory

Możesz użyć ogólnego zasobu kontenera jako obrazu użytego w ramach zadania lub można go również użyć w przypadku zadań kontenera. Jeśli potok wymaga obsługi co najmniej jednej usługi, należy utworzyć kontenery usług i połączyć się z nimi. Za pomocą woluminów można udostępniać dane między usługami.

Aby korzystać z obrazów usługi ACR, możesz użyć typu zasobu kontenera pierwszej klasy dla usługi Azure Container Registry (ACR). Tego typu zasobów można używać w ramach zadań, a także do włączania automatycznych wyzwalaczy potoku. Aby korzystać z automatycznych wyzwalaczy potoku, musisz mieć uprawnienia współautora lub właściciela usługi ACR. Aby uzyskać więcej informacji, zobacz Role i uprawnienia usługi Azure Container Registry.

resources:          # types: pipelines | repositories | containers | builds | packages
  containers:
  - container: string # identifier for the container resource      
    type: string # type of the registry like ACR, GCR etc. 
    azureSubscription: string # Azure subscription (ARM service connection) for container registry;
    resourceGroup: string # resource group for your ACR
    registry: string # registry for container images
    repository: string # name of the container image repository in ACR
    trigger: # Triggers aren't enabled by default and need to be set explicitly
      enabled: boolean # set to 'true' to trigger on all image tags if 'tags' is unset.
      tags:
        include: [ string ]  # image tags to consider the trigger events, optional; defaults to any new tag
        exclude: [ string ]  # image tags on discard the trigger events, optional; defaults to none

Uwaga

Składnia używana do włączania wyzwalaczy kontenera dla wszystkich tagów obrazów (enabled: 'true') różni się od składni używanej dla innych wyzwalaczy zasobów. Zwróć szczególną uwagę na użycie poprawnej składni dla określonego zasobu.

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ą przekazywane do potoku w postaci zmiennych. Informacje, takie jak obraz, rejestr i szczegóły połączenia, są dostępne we wszystkich zadaniach, które mają być używane 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.

resources.container.<Alias>.type
resources.container.<Alias>.registry
resources.container.<Alias>.repository
resources.container.<Alias>.tag 
resources.container.<Alias>.digest
resources.container.<Alias>.URI
resources.container.<Alias>.location

Zmienna lokalizacji ma zastosowanie tylko dla ACR typu zasobów kontenera.

Definiowanie packages zasobu

Pakiety NuGet i npm GitHub można używać jako zasobu w potokach YAML.

Podczas określania package zasobów ustaw pakiet jako NuGet lub npm. Możesz również włączyć automatyczne wyzwalacze potoku po wydaniu nowej wersji pakietu.

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 paT.

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

resources:
  packages:
    - package: myPackageAlias # alias for the package resource
      type: Npm # type of the package NuGet/npm
      connection: GitHubConnectionName # GitHub service connection with the PAT type
      name: nugetTest/nodeapp # <Repository>/<Name of the package>
      version: 1.0.1 # Version of the package to consume; Optional; Defaults to latest
      trigger: true # To enable automated triggers (true/false); Optional; Defaults to no triggers

Definiowanie webhooks zasobu

Uwaga

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

W przypadku innych zasobów (takich jak potoki, kontenery, kompilacja i pakiety) można korzystać z artefaktów i włączać automatyczne wyzwalacze. Nie można jednak zautomatyzować procesu wdrażania w oparciu o inne zewnętrzne zdarzenia lub usługi. Zasób webhooks umożliwia integrację potoku z dowolną usługą zewnętrzną i automatyzację przepływu pracy. Możesz subskrybować dowolne zdarzenia zewnętrzne za pośrednictwem webhooków (GitHub, GitHub Enterprise, Nexus, Artifactory itd.) i uruchamiać swoje potoki.

Wykonaj następujące kroki, aby skonfigurować wyzwalacze elementu webhook.

  1. Skonfiguruj element webhook w usłudze zewnętrznej. Podczas tworzenia elementu webhook należy podać następujące informacje:

    • Adres URL żądania

      https://dev.azure.com/<ADO 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.

  2. Utwórz nowe połączenie usługi "Przychodzący element webhook". To połączenie jest nowo wprowadzonym typem połączenia usługi, który umożliwia zdefiniowanie następujących ważnych informacji:

    • Nazwa elementu webhook: nazwa elementu webhook powinna być zgodna z elementem webhook utworzonym w usłudze zewnętrznej.
    • Nagłówek HTTP — nazwa nagłówka HTTP w żądaniu, który zawiera wartość skrótu HMAC-SHA1 ładunku na potrzeby weryfikacji żądania. Na przykład w usłudze GitHub nagłówek żądania to "X-Hub-Signature".
    • Wpis tajny — klucz tajny służy do weryfikowania skrótu HMAC-SHA1 ładunku używanego do weryfikacji żądania przychodzącego (opcjonalnie). Jeśli podczas tworzenia webhooka użyłeś klucza tajnego, musisz podać ten sam tajny klucz.

    Przychodzące połączenie usługi elementu webhook

  3. Nowy typ zasobu o nazwie webhooks jest wprowadzany w potokach YAML. Aby zasubskrybować zdarzenie elementu webhook, zdefiniuj zasób elementu webhook w potoku i wskaż je 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. Zużyj dane ładunku w postaci zmiennych w zadaniach.

  4. Za każdym razem, gdy przychodzące połączenie usługi elementu webhook odbiera zdarzenie elementu webhook, zostanie wyzwolony nowy przebieg dla wszystkich potoków subskrybowanych do zdarzenia elementu webhook. Dane ładunku JSON można używać w zadaniach przy użyciu formatu ${{ parameters.<WebhookAlias>.<JSONPath>}}

resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias           ### Webhook alias
      connection: IncomingWebhookConnection    ### Incoming webhook service connection
      filters:                                 ### List of JSON parameters to filter; Parameters are AND'ed
        - path: JSONParameterPath              ### JSON path in the payload
          value: JSONParameterExpectedValue    ### Expected value in the path provided

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 i 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.

Ręczny selektor wersji dla zasobów w oknie dialogowym tworzenia przebiegu

Po ręcznym wyzwoleniu potoku YAML ciągłego wdrażania automatycznie oceniamy domyślną wersję zasobów zdefiniowanych w potoku na podstawie podanych danych wejściowych. Można jednak wybrać inną wersję z selektora wersji zasobów podczas tworzenia przebiegu.

  1. W okienku Tworzenie przebiegu wybierz pozycję Zasoby. Zostanie wyświetlona lista zasobów użytych w tym potoku.

  2. Wybierz zasób i wybierz określoną wersję z listy dostępnych wersji. Selektor wersji zasobów jest obsługiwany dla zasobów potoku, kompilacji, repozytorium, kontenera i pakietu.

    Selektor wersji potoku

W przypadku zasobów potoku można zobaczyć wszystkie dostępne uruchomienia we wszystkich gałęziach. Wyszukaj je na podstawie numeru potoku lub gałęzi. Wybierz 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 wygenerował wszystkie potrzebne artefakty. Nie musisz czekać na ukończenie lub ponowne uruchomienie przebiegu ciągłej integracji z powodu niepowiązanego błędu etapu w przebiegu ciągłej integracji. Jednak rozważamy pomyślne ukończenie przebiegów ciągłej integracji tylko wtedy, gdy oceniamy domyślną wersję zaplanowanych wyzwalaczy lub jeśli nie używasz selektora wersji ręcznej.

W przypadku zasobów, w których nie można pobrać dostępnych wersji, takich jak pakiety GitHub, w selektorze wersji jest wyświetlane pole tekstowe, dzięki czemu można podać wersję przebiegu do wybrania.

Autoryzowanie potoku YAML

Zasoby muszą być autoryzowane, zanim będą mogły być używane. Właściciel zasobu kontroluje użytkowników i potoki, które mogą uzyskiwać dostęp do tego zasobu. Potok musi być autoryzowany do korzystania z zasobu. Zobacz następujące sposoby autoryzowania potoku YAML.

  • Przejdź do środowiska administracyjnego zasobu. Na przykład grupy zmiennych i bezpieczne pliki są zarządzane na stronie Biblioteka w obszarze Potoki. Pule agentów i połączenia usług są zarządzane w ustawieniach programu Project. W tym miejscu możesz autoryzować wszystkie potoki , aby uzyskać dostęp do tego zasobu. Ta autoryzacja jest wygodna, jeśli nie musisz ograniczać dostępu do zasobu — na przykład przetestować zasoby.

  • Podczas tworzenia potoku po raz pierwszy wszystkie zasoby, do których odwołuje się plik YAML, są automatycznie autoryzowane do użycia przez potok, jeśli jesteś członkiem roli Użytkownik dla tego zasobu. Dlatego zasoby, do których odwołuje się plik YAML podczas tworzenia potoku, są automatycznie autoryzowane.

  • Po wprowadzeniu zmian w pliku YAML i dodaniu zasobów kompilacja kończy się niepowodzeniem z powodu błędu podobnego do następującego: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    W takim przypadku 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ę. Po autoryzowanym zasobie możesz rozpocząć nową kompilację.

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

Ustawianie sprawdzania zatwierdzenia dla zasobów

Możesz ręcznie kontrolować, kiedy zasób jest uruchamiany za pomocą kontroli zatwierdzenia i szablonów. W przypadku sprawdzania zatwierdzenia wymaganego szablonu można wymagać dowolnego potoku przy użyciu zasobu lub środowiska, a także rozszerzyć go z określonego szablonu YAML. Ustawienie wymaganego zatwierdzenia szablonu zwiększa bezpieczeństwo. Upewnij się, że zasób jest używany tylko w określonych warunkach z szablonem. Dowiedz się więcej o sposobie ulepszania zabezpieczeń potoku za pomocą szablonów i zasobów.

Identyfikowalność

Zapewniamy pełną możliwość śledzenia dla dowolnego zasobu używanego na poziomie zadania potoku lub wdrożenia.

Możliwość śledzenia potoku

Dla każdego uruchomienia potoku są wyświetlane następujące informacje.

  • Zasób, który wyzwolił potok, jeśli jest wyzwalany przez zasób.

    Wyzwalacz zasobu w potoku

  • Wersja zasobu i użytych artefaktów.

    Używane artefakty w przebiegu potoku

  • Zatwierdzenia skojarzone z każdym zasobem.

    Zatwierdzenia w przebiegu potoku

  • 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. Poniższy widok zawiera zasoby używane w ramach zadań wdrażania i skojarzonych z nimi zatwierdzeń i elementów roboczych.

Zatwierdzenia w środowisku

Wyświetlanie informacji o skojarzonych potokach 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 zużywają potok ciągłej integracji. Możesz zobaczyć listę potoków YAML ciągłego wdrażania, w których jest używany potok ciągłej pipeline 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". W tym miejscu można znaleźć wszystkie uruchomienia potoku, które korzystają z potoku i artefaktów.

Informacje o potokach ciągłego wdrażania w potoku ciągłej integracji

Problemy z wyzwalaczem zasobów YAML — obsługa i możliwość śledzenia

Może to być mylące, gdy wyzwalacze potoku nie będą wykonywane. Dodaliśmy nowy element menu na stronie definicji potoku o nazwie Problemy z wyzwalaczem, gdzie można dowiedzieć się, dlaczego wyzwalacze nie są wykonywane. Aby uzyskać dostęp do tej strony, otwórz historię potoku. Problemy z wyzwalaczem są dostępne tylko dla zasobów innych niż repozytorium.

Wybierz pozycję Wyzwól problemy z nawigacją.

Wyzwalacze zasobów mogą nie działać z następujących powodów.

  • Jeśli źródło podanego połączenia z usługą jest nieprawidłowe lub jeśli w wyzwalaczu występują błędy składniowe, wyzwalacz nie jest skonfigurowany, co powoduje błąd.

  • Jeśli warunki wyzwalacza nie są zgodne, wyzwalacz nie zostanie wykonany. Zostanie wyświetlone ostrzeżenie, aby zrozumieć, dlaczego warunki nie zostały dopasowane.

    Problemy z wyzwalaczem — obsługa

Następne kroki

Dodawanie i używanie grup zmiennych

Często zadawane pytania

Dlaczego należy używać potoków resources zamiast skrótu download ?

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 pobrać artefakty w zadaniach kompilacji lub zastąpić zachowanie pobierania w zadaniach wdrażania za pomocą polecenia download. Aby uzyskać więcej informacji, zobacz steps.download.

Dlaczego należy używać resources zamiast zadania Pobieranie artefaktów potoku?

Jeśli bezpośrednio używasz zadania Pobierz artefakty potoku, pomijasz możliwość śledzenia i wyzwalacze. Czasami warto użyć zadania Pobierz artefakty potoku bezpośrednio. Na przykład może istnieć zadanie skryptu przechowywane w innym szablonie, a zadanie skryptu wymaga pobrania artefaktów z kompilacji. Możesz też nie wiedzieć, czy ktoś używający szablonu chce dodać zasób potoku. 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?

Należy skonfigurować klasyczny potok wydania, ponieważ wyzwalacz zasobów kontenerów nie jest dostępny dla potoków YAML usługi Docker Hub.

  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. Wybierz przestrzeń nazw, repozytorium, wersję i alias źródłowy.

    Dodaj artefakt usługi Docker Hub.

  3. Wybierz wyzwalacz i przełącz wyzwalacz ciągłego wdrażania na wartość Włącz. Po każdym wypchnięciu platformy Docker utworzysz wydanie do wybranego repozytorium.

  4. Utwórz nowy etap i zadanie. Dodaj dwa zadania, logowanie do platformy Docker i powłokę Bash:

  • Zadanie platformy login Docker zawiera akcję i rejestruje Cię w usłudze Docker Hub.

  • Zadanie powłoki Bash uruchamia polecenie docker pull <hub-user>/<repo-name>[:<tag>]. Zastąp hub-userwartości , repo-namei tag wartościami.

    Dodaj zadania logowania platformy Docker i powłoki Bash.

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

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

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

    resources:
  webhooks:
    - webhook: MyWebhookTriggerAlias
      connection: MyServiceConnection

  3. Uruchom swój potok. Po uruchomieniu potoku element webhook zostanie utworzony 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ź kodu stanu 200, element webhook jest gotowy do użycia przez potok. Jeśli otrzymasz odpowiedź kodu 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ą.

    1. Otwórz potok.
    2. Zaznacz Edytuj.
    3. Wybierz menu Wybierz menu Więcej akcji więcej akcji .
    4. Wybierz pozycję Wyzwalacze>YAML>Pobierz źródła.
    5. Przejdź do gałęzi Domyślnej dla kompilacji ręcznych i zaplanowanych , aby zaktualizować gałąź funkcji.
    6. Wybierz pozycję Zapisz i kolejkę.
    7. 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.