Definir recursos no YAML

Serviços de DevOps do Azure | Azure DevOps Server 2022 - Azure DevOps Server 2019

Os recursos no YAML representam origens de pipelines, compilações, repositórios, contentores, pacotes e webhooks. Os recursos também fornecem a rastreabilidade total dos serviços usados em seu pipeline, incluindo a versão, artefatos, confirmações associadas e itens de trabalho. Quando define um recurso, este pode ser consumido em qualquer parte do pipeline. Além disso, você pode automatizar totalmente seu fluxo de trabalho de DevOps inscrevendo-se para acionar eventos em seus recursos.

Para obter mais informações, consulte Sobre recursos e a definição de esquema YAML de recursos.

Esquema

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

Variáveis

Quando um recurso aciona um pipeline, as seguintes variáveis são definidas:

resources.triggeringAlias
resources.triggeringCategory

Esses valores ficarão vazios se um recurso não acionar uma execução de pipeline. A variável Build.Reason deve ser ResourceTrigger para que esses valores sejam definidos.

Definir um pipelines recurso

Se você tiver um pipeline que produz artefatos, poderá consumi-los definindo um pipelines recurso. pipelines é um recurso dedicado apenas para o Azure Pipelines. Você também pode definir gatilhos em um recurso de pipeline para seus fluxos de trabalho de CD.

Em sua definição de recurso, pipeline é um valor exclusivo que você pode usar para fazer referência ao recurso de pipeline posteriormente. source é o nome do pipeline que produz um artefato. Use o rótulo definido por pipeline para fazer referência ao recurso de pipeline de outras partes do pipeline, como ao usar variáveis de recurso de pipeline ou baixar artefatos.

Para obter uma maneira alternativa de baixar pipelines, consulte as tarefas em Pipeline Artifacts.

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
    version: string  # the pipeline run number to pick the artifact, defaults to latest pipeline successful 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 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

Importante

Quando você define um gatilho de recurso, se seu recurso de pipeline for do mesmo repositório (digamos self) que o pipeline atual, o acionamento segue a mesma ramificação e confirmação na qual o evento é gerado. Mas, se o recurso de pipeline for de um repositório diferente, o pipeline atual será acionado na ramificação padrão do repositório automático.

Avaliação da versão do artefato

A versão dos artefatos do pipeline de recursos depende de como o pipeline é acionado.

Se o pipeline for executado porque você o acionou manualmente ou devido a uma execução agendada, a versão da versão do artefato será definida pelos valores das versionpropriedades , branche tags .

Propriedades especificadas Versão do artefato
version Os artefatos da compilação com o número de execução especificado
branch Os artefatos da compilação mais recente executada na ramificação especificada
tags Lista Os artefatos da compilação mais recente que tem todas as tags especificadas
branch e tags lista Os artefatos da compilação mais recente executada na ramificação especificada e que tem todas as tags especificadas
None Os artefatos da última construção em todos os ramos

Vamos ver um exemplo. Digamos que seu pipeline contenha a seguinte definição de recurso.

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

Quando você aciona manualmente o pipeline para ser executado, a versão dos artefatos do MyCIAlias pipeline é a última compilação feita na main ramificação e que tem as Production tags e PrepProduction .

Quando o pipeline é acionado porque um de seus pipelines de recursos é concluído, a versão dos artefatos é a do pipeline de acionamento. Os valores das versionpropriedades , branche são tags ignorados.

Gatilhos especificados Resultado
branches Uma nova execução do pipeline atual é acionada sempre que o pipeline de recursos conclui com êxito uma execução nas include ramificações
tags Uma nova execução do pipeline atual é acionada sempre que o pipeline de recursos conclui com êxito uma execução marcada com todas as tags especificadas
stages Uma nova execução do pipeline atual é acionada sempre que o pipeline de recursos executou com êxito o stages
branches, , tagse stages Uma nova execução do pipeline atual é acionada sempre que a execução do pipeline de recursos satisfaz todas as condições de ramificação, tags e estágios
trigger: true Uma nova execução do pipeline atual é acionada sempre que o pipeline de recursos conclui com êxito uma execução
Nenhumas Nenhuma nova execução do pipeline atual é acionada quando o pipeline de recursos conclui com êxito uma execução

Vamos ver um exemplo. Digamos que seu pipeline contenha a seguinte definição de recurso.

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

Seu pipeline será executado sempre que o SmartHotel-CI pipeline for executado em uma das releases ramificações ou na main ramificação, for marcado com ambos Verified e , e tiver concluído os Production estágios e PreProductionSigned.

download para gasodutos

Todos os artefatos do pipeline atual e de todos os pipeline recursos são automaticamente baixados e disponibilizados no início de cada deployment trabalho. Você pode substituir esse comportamento. Para obter mais informações, consulte Artefatos de pipeline. Os artefatos regulares de "trabalho" não são baixados automaticamente. Use download explicitamente quando necessário.

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

Os artefatos do recurso são baixados para a pipeline$(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier> pasta.

Variáveis de recurso de pipeline

Em cada execução, os metadados de um recurso de pipeline estão disponíveis para todos os trabalhos na forma de variáveis predefinidas. O <Alias> é o identificador que você forneceu para seu recurso de pipeline. As variáveis de recursos de pipeline só estão disponíveis em tempo de execução.

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

Para obter mais informações, consulte Metadados de recursos de pipeline como variáveis predefinidas.

Definir um builds recurso

Se você tiver um sistema de compilação de CI externo que produz artefatos, poderá consumir artefatos com um builds recurso. Um builds recurso pode ser qualquer sistema de CI externo como Jenkins, TeamCity, CircleCI e assim por diante.

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 é uma categoria extensível. Você pode escrever uma extensão para consumir artefatos do seu serviço de compilações e introduzir um novo tipo de serviço como parte do builds. Jenkins é um tipo de recurso em builds.

Importante

Os gatilhos só são suportados para Jenkins hospedados onde o Azure DevOps tem linha de visão com o servidor Jenkins.

downloadBuild tarefa para compilações

Você pode consumir artefatos do build recurso como parte de seus trabalhos usando a downloadBuild tarefa. Com base no tipo de recurso definido, essa tarefa é automaticamente resolvida para a tarefa de download correspondente para o serviço durante o tempo de build execução.

Os artefatos do recurso são baixados para a build$(PIPELINE.WORKSPACE)/<build-identifier>/ pasta.

Importante

build Os artefatos de recursos não são baixados automaticamente em seus jobs/deploy-jobs. Você precisa adicionar explicitamente a downloadBuild tarefa para consumir os artefatos.

- 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

Definir um repositories recurso

Se o pipeline tiver modelos em outro repositório ou se você quiser usar o check-out multi-repo com um repositório que exija uma conexão de serviço, informe o sistema sobre esse repositório. A repository palavra-chave permite especificar um repositório externo.

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.

Type

Os pipelines suportam os seguintes valores para o tipo de repositório: git, , githubenterprisegithube bitbucket. O git tipo refere-se aos repositórios Git do Azure Repos.

Tipo especificado Resultado Exemplo
type: git O name valor refere-se a outro repositório no mesmo projeto. name: otherRepo Para fazer referência a um repositório em outro projeto dentro da mesma organização, prefixe o nome com o nome desse projeto. Um exemplo é name: OtherProject/otherRepo.
type: github O name valor é o nome completo do repositório GitHub e inclui o usuário ou organização. name: Microsoft/vscode
type: githubenterprise o valor é o nome completo do repositório GitHub Enterprise e inclui o name usuário ou organização. name: Microsoft/vscode
type: bitbucket O name valor é o nome completo do repositório Bitbucket Cloud e inclui o usuário ou organização. name: MyBitbucket/vscode

Os repositórios do GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.

Os repositórios Bitbucket Cloud requerem uma conexão de serviço Bitbucket Cloud para autorização.

Variáveis

Em cada execução, os metadados de um recurso de repositório estão disponíveis para todos os trabalhos na forma de variáveis de tempo de execução. O <Alias> é o identificador que você forneceu para o recurso do repositório.

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

Variáveis

Em cada execução, os metadados de um recurso de repositório estão disponíveis para todos os trabalhos na forma de variáveis de tempo de execução. O <Alias> é o identificador que você forneceu para o recurso do repositório.

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

Use checkout para consumir repositório

Use checkout a palavra-chave para consumir seus repositórios definidos como parte do repository recurso.

Esquema

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.

Os repositórios do repository recurso não são sincronizados automaticamente em seus trabalhos. Use checkout para buscar seus repositórios como parte de seus trabalhos.

Para obter mais informações, consulte Verificar vários repositórios em seu pipeline.

Definir um containers recurso

Se você precisar consumir uma imagem de contêiner como parte de seu pipeline de integração contínua/entrega contínua (CI/CD), poderá obtê-lo usando containerso . Um recurso de contêiner pode ser um Registro do Docker público ou privado ou um Registro de Contêiner do Azure.

Se você precisar consumir imagens do registro do Docker como parte do seu pipeline, poderá definir um recurso de contêiner genérico (não type palavra-chave necessária).

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

Você pode usar um recurso de contêiner genérico como uma imagem consumida como parte de seu trabalho, ou ele também pode ser usado para trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, convém criar e conectar-se a contêineres de serviço. Você pode usar volumes para compartilhar dados entre serviços.

Você pode usar um tipo de recurso de contêiner de primeira classe para o Registro de Contêiner do Azure (ACR) para consumir suas imagens ACR. Esse tipo de recursos pode ser usado como parte de seus trabalhos e também para habilitar gatilhos automáticos de pipeline. Você precisa ter permissões de Colaborador ou Proprietário para que o ACR use gatilhos automáticos de pipeline. Para obter mais informações, consulte Funções e permissões do Registro de Contêiner do Azure.

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

Nota

A sintaxe usada para habilitar gatilhos de contêiner para todas as marcas de imagem (enabled: 'true') é diferente da sintaxe usada para outros gatilhos de recurso. Preste muita atenção para usar a sintaxe correta para um recurso específico.

Nota

As conexões de serviço que usam a federação de identidades de carga de trabalho não são suportadas no azureSubscription.

Variáveis de recurso de contêiner

Depois de definir um contêiner como um recurso, os metadados da imagem do contêiner são passados para o pipeline na forma de variáveis. Informações como imagem, registro e detalhes de conexão estão acessíveis em todos os trabalhos a serem usados em suas tarefas de implantação de contêiner.

As variáveis de recurso de contêiner funcionam com o Docker e o Registro de Contêiner do Azure. Não é possível usar variáveis de recurso de contêiner para contêineres de imagem locais.

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

A variável de localização só é aplicável para ACR o tipo de recursos de contêiner.

Definir um packages recurso

Você pode consumir pacotes NuGet e npm GitHub como um recurso em pipelines YAML.

Ao especificar package recursos, defina o pacote como NuGet ou npm. Você também pode habilitar gatilhos de pipeline automatizados quando uma nova versão do pacote for lançada.

Para usar pacotes do GitHub, use a autenticação baseada em token de acesso pessoal (PAT) e crie uma conexão de serviço do GitHub que use PATs.

Por padrão, os pacotes não são baixados automaticamente em trabalhos. Para fazer o download, use getPackageo .

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

Definir um webhooks recurso

Nota

Webhooks foram lançados no Azure DevOps Server 2020.1.

Com outros recursos (como pipelines, contentores, compilações e pacotes), pode consumir artefactos e ativar acionadores automatizados. No entanto, não pode automatizar o seu processo de implementação com base noutros eventos ou serviços externos. O webhooks recurso permite que você integre seu pipeline com qualquer serviço externo e automatize o fluxo de trabalho. Pode subscrever quaisquer eventos externos através dos respetivos webhooks (GitHub, GitHub Enterprise, Nexus, Artifactory, etc.) e acionar os seus pipelines.

Execute as etapas a seguir para configurar os gatilhos do webhook.

  1. Configure um webhook no seu serviço externo. Ao criar seu webhook, você precisa fornecer as seguintes informações:

    • URL do pedido

      https://dev.azure.com/<ADO Organization>/_apis/public/distributedtask/webhooks/<WebHook Name>?api-version=6.0-preview
      
    • Segredo - Opcional. Se você precisar proteger sua carga JSON útil, forneça o valor Secret .

  2. Crie uma nova conexão de serviço "Incoming Webhook". Esta ligação é um Tipo de Ligação de Serviço recentemente introduzido que permite definir as seguintes informações importantes:

    • Nome do Webhook: O nome do webhook deve corresponder ao webhook criado no seu serviço externo.
    • Cabeçalho HTTP - O nome do cabeçalho HTTP na solicitação que contém o valor de hash HMAC-SHA1 da carga útil para verificação da solicitação. Por exemplo, para o GitHub, o cabeçalho da solicitação é "X-Hub-Signature".
    • Segredo - O segredo é usado para verificar o hash HMAC-SHA1 da carga útil usado para verificação da solicitação de entrada (opcional). Se utilizou um segredo ao criar o seu webhook, tem de fornecer a mesma chave secreta.

    Incoming Webhook Service connection

  3. Um novo tipo de recurso chamado webhooks é introduzido em pipelines YAML. Para se inscrever em um evento de webhook, defina um recurso de webhook em seu pipeline e aponte-o para a conexão de serviço de webhook de entrada. Você também pode definir mais filtros no recurso webhook, com base nos dados de carga JSON para personalizar os gatilhos para cada pipeline. Consuma os dados de carga útil na forma de variáveis em seus trabalhos.

  4. Sempre que a conexão do serviço Webhook de entrada recebe um evento webhook, uma nova execução é acionada para todos os pipelines inscritos no evento webhook. Você pode consumir os dados de carga JSON em seus trabalhos usando o formato ${{ 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

Os Webhooks automatizam seu fluxo de trabalho com base em qualquer evento de webhook externo que não seja suportado por recursos de primeira classe, como pipelines, compilações, contêineres e pacotes. Além disso, para serviços locais em que o Azure DevOps não tem visibilidade do processo, você pode configurar webhooks no serviço e acionar seus pipelines automaticamente.

Seletor manual de versão para recursos na caixa de diálogo criar execução

Quando você aciona manualmente um pipeline YAML de CD, avaliamos automaticamente a versão padrão para os recursos definidos no pipeline, com base nas entradas fornecidas. No entanto, você pode optar por escolher uma versão diferente do seletor de versão de recurso ao criar uma execução.

  1. No painel Criar execução, selecione Recursos. Você verá uma lista de recursos consumidos nesse pipeline.

  2. Selecione um recurso e escolha uma versão específica na lista de versões disponíveis. O seletor de versão de recursos é suportado para recursos de pipeline, compilação, repositório, contêiner e pacote.

    Pipeline Version Picker

Para recursos de pipeline, você pode ver todas as execuções disponíveis em todas as ramificações. Pesquise-os com base no número do pipeline ou ramo. E escolha uma execução bem-sucedida, com falha ou em andamento. Essa flexibilidade garante que você possa executar seu pipeline de CD se tiver certeza de que ele produziu todos os artefatos de que você precisa. Você não precisa esperar que a execução de CI seja concluída ou executada novamente devido a uma falha de estágio não relacionada na execução de CI. No entanto, só consideramos execuções de CI concluídas com êxito quando avaliamos a versão padrão para gatilhos agendados ou se você não usa o seletor de versão manual.

Para recursos em que você não pode buscar versões disponíveis, como pacotes do GitHub, mostramos uma caixa de texto como parte do seletor de versão para que você possa fornecer a versão para a execução a ser escolhida.

Autorizar um pipeline YAML

Os recursos devem ser autorizados antes de poderem ser utilizados. Um proprietário de recurso controla os usuários e pipelines que podem acessar esse recurso. O pipeline deve ser autorizado a usar o recurso. Veja as seguintes maneiras de autorizar um pipeline YAML.

  • Vá para a experiência de administração do recurso. Por exemplo, grupos variáveis e arquivos seguros são gerenciados na página Biblioteca em Pipelines. Os pools de agentes e as conexões de serviço são gerenciados nas configurações do Project. Aqui você pode autorizar todos os pipelines a acessar esse recurso. Essa autorização é conveniente se você não tiver a necessidade de restringir o acesso a um recurso - por exemplo, recursos de teste.

  • Quando você cria um pipeline pela primeira vez, todos os recursos referenciados no arquivo YAML são automaticamente autorizados para uso pelo pipeline, se você for membro da função Usuário desse recurso. Assim, os recursos que são referenciados no arquivo YAML quando você cria um pipeline são automaticamente autorizados.

  • Quando você faz alterações no arquivo YAML e adiciona recursos, a compilação falha com um erro semelhante ao seguinte erro: Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use.

    Nesse caso, você verá uma opção para autorizar os recursos na compilação com falha. Se você for membro da função Usuário do recurso, poderá selecionar essa opção. Depois que os recursos forem autorizados, você poderá iniciar uma nova compilação.

  • Verifique se as funções de segurança do pool de agentes para seu projeto estão corretas.

Definir verificações de aprovação para recursos

Você pode controlar manualmente quando um recurso é executado com verificações de aprovação e modelos. Com a verificação de aprovação de modelo necessária, você pode exigir que qualquer pipeline usando um recurso ou ambiente também se estenda de um modelo YAML específico. Definir uma aprovação de modelo necessária aumenta a segurança. Certifique-se de que seu recurso só seja usado sob condições específicas com um modelo. Saiba mais sobre como melhorar a segurança do pipeline com modelos e recursos.

Rastreabilidade

Fornecemos rastreabilidade total para qualquer recurso consumido em um nível de trabalho de pipeline ou implantação.

Rastreabilidade de oleodutos

Para cada execução de pipeline, mostramos as seguintes informações.

  • O recurso que acionou o pipeline, se ele for acionado por um recurso.

    Resource trigger in a pipeline

  • Versão do recurso e dos artefatos consumidos.

    Consumed artifacts in pipeline run

  • Confirmações associadas a cada recurso.

    Commits in pipeline run

  • Itens de trabalho associados a cada recurso.

Rastreabilidade de ambiente

Sempre que um pipeline é implantado em um ambiente, você pode ver uma lista de recursos que são consumidos. A exibição a seguir inclui recursos consumidos como parte dos trabalhos de implantação e suas confirmações e itens de trabalho associados.

Commits in environment

Mostrar informações de pipelines de CD associados em pipelines de CI

Para fornecer rastreabilidade de ponta a ponta, você pode rastrear quais pipelines de CD estão consumindo um pipeline de CI. Você pode ver a lista de pipelines YAML de CD executados onde uma execução de pipeline de CI é consumida através do pipeline recurso. Se outros pipelines consumirem seu pipeline de CI, você verá uma guia "Pipelines associados" na visualização de execução. Aqui você pode encontrar todas as execuções de pipeline que consomem seu pipeline e artefatos dele.

CD pipelines information in CI pipeline

Suporte e rastreabilidade de problemas de gatilho de recursos YAML

Pode ser confuso quando os gatilhos de pipeline não são executados. Adicionamos um novo item de menu na página de definição de pipeline chamado Problemas de gatilho, onde você pode saber por que os gatilhos não estão sendo executados. Para acessar esta página, abra seu histórico de pipeline. O Trigger Issues só está disponível para recursos que não sejam do repositório.

Select Trigger Issues from the navigation.

Os gatilhos de recursos podem falhar na execução pelos seguintes motivos.

  • Se a origem da conexão de serviço fornecida for inválida ou se houver erros de sintaxe no gatilho, o gatilho não será configurado, resultando em um erro.

  • Se as condições do gatilho não forem correspondidas, o gatilho não será executado. Um aviso é exibido para que você possa entender por que as condições não foram correspondidas.

    Trigger issues supportability

Próximos passos

FAQ

Por que devo usar pipelines resources em vez do download atalho?

Usar um recurso é uma maneira de consumir artefatos de um pipelines pipeline de CI e também configurar gatilhos automatizados. Um recurso oferece visibilidade total do processo, exibindo a versão consumida, artefatos, confirmações e itens de trabalho. Quando você define um recurso de pipeline, os artefatos associados são baixados automaticamente em trabalhos de implantação.

Você pode optar por baixar os artefatos em trabalhos de compilação ou substituir o comportamento de download em trabalhos de implantação com download. Para obter mais informações, consulte steps.download.

Por que devo usar resources em vez da tarefa Baixar artefatos de pipeline?

Quando você usa a tarefa Baixar artefatos de pipeline diretamente, você perde a rastreabilidade e os gatilhos. Às vezes, faz sentido usar a tarefa Download Pipeline Artifacts diretamente. Por exemplo, você pode ter uma tarefa de script armazenada em um modelo diferente e a tarefa de script requer artefatos de uma compilação para ser baixada. Ou, você pode não saber se alguém usando um modelo deseja adicionar um recurso de pipeline. Para evitar dependências, você pode usar a tarefa Baixar Artefatos de Pipeline para passar todas as informações de compilação para uma tarefa.

Como posso acionar uma execução de pipeline quando minha imagem do Docker Hub é atualizada?

Você precisará configurar um pipeline de liberação clássico porque o gatilho de recursos de contêineres não está disponível para pipelines do Docker Hub for YAML.

  1. Crie uma nova conexão de serviço do Docker Hub.

  2. Crie um pipeline de versão clássico e adicione um artefato do Docker Hub. Defina sua conexão de serviço. Selecione o namespace, o repositório, a versão e o alias de origem.

    Add a Docker Hub artifact.

  3. Selecione o gatilho e alterne o gatilho de implantação contínua para Ativar. Você criará uma versão sempre que ocorrer um push do Docker no repositório selecionado.

  4. Crie um novo estágio e trabalho. Adicione duas tarefas, login no Docker e Bash:

  • A tarefa do Docker tem a login ação e faz login no Docker Hub.

  • A tarefa Bash é executada docker pull <hub-user>/<repo-name>[:<tag>]. Substitua hub-user, , repo-namee tag pelos seus valores.

    Add Docker login and Bash tasks.

Como posso validar e solucionar problemas de webhooks?

  1. Crie uma conexão de serviço.

  2. Faça referência à sua conexão de serviço e nomeie webhooks seu webhook na seção.

    resources:
      webhooks:
        - webhook: MyWebhookTriggerAlias
          connection: MyServiceConnection
    
  3. Execute os seus pipelines. Quando você executa seu pipeline, o webhook será criado no Azure como uma tarefa distribuída para sua organização.

  4. Execute uma chamada de POST API com JSON válido no corpo para https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Se você receber uma resposta de código de status 200, seu webhook estará pronto para consumo pelo seu pipeline. Se você receber uma resposta de código de status 500 com o erro Cannot find webhook for the given webHookId ..., seu código pode estar em uma ramificação que não é sua ramificação padrão.

    1. Abra seu pipeline.
    2. Selecione Editar.
    3. Selecione o menu Select more actions menu mais ações .
    4. Selecione Triggers>YAML>Get Sources.
    5. Vá para Ramificação padrão para compilações manuais e agendadas para atualizar sua ramificação de recurso.
    6. Selecione Salvar fila & .
    7. Depois que esse pipeline for executado com êxito, execute uma POST chamada de API com JSON válido no corpo para https://dev.azure.com/{organization}/_apis/public/distributedtask/webhooks/{webhook-name}?api-version={apiversion}. Agora você deve receber uma resposta de código de status 200.