Recursos em pipelines do YAML

Azure DevOps Services | Azure DevOps Server 2022 - Azure DevOps Server 2019

Este artigo discute recursos para pipelines do YAML. Um recurso é qualquer coisa usada por um pipeline que existe fora do pipeline. Depois de definir um recurso, você pode consumi-lo em qualquer lugar no seu pipeline.

Os recursos fornecem uma total rastreabilidade dos serviços usados no seu pipeline, incluindo a versão, os artefatos, os commits associados e os itens de trabalho. Você pode automatizar totalmente os fluxos de trabalho de DevOps fazendo uma assinatura para disparar eventos nos seus recursos.

Esquema de recursos

Os recursos em YAML representam fontes de pipelines, builds, repositórios, contêineres, pacotes e webhooks. Para obter informações completas sobre o esquema, consulte a definição de recursos na referência de esquema YAML para Azure Pipelines.

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

resources.triggeringAlias
resources.triggeringCategory

A variável Build.Reason deve ser ResourceTrigger para que esses valores sejam definidos. Os valores estarão vazios se um recurso não tiver disparado a execução de pipeline.

Definição de recurso de pipelines

Se você tiver um pipeline que produz artefatos, poderá consumir os artefatos definindo um recurso pipelines. Somente o Azure Pipelines pode usar o recurso pipelines. Você pode definir gatilhos para seus fluxos de trabalho de implantação contínua (CD) em um recurso do pipeline.

Na sua definição de recurso, pipeline é um valor exclusivo que você pode usar para referenciar o recurso do pipeline posteriormente no seu pipeline. O source é o nome do pipeline que produziu o artefato do pipeline. Para obter informações completas sobre o esquema, consulte a definição de resources.pipelines.pipeline.

Use o rótulo definido por pipeline para referenciar o recurso do pipeline de outras partes do pipeline, como ao usar variáveis de recurso do pipeline ou baixar artefatos. Para obter uma maneira alternativa de baixar artefatos de pipeline, consulte Baixar artefatos.

Exemplo de definições de recurso de pipeline

O exemplo a seguir consome artefatos de um pipeline no mesmo projeto.

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

Para consumir um pipeline de outro projeto, inclua o nome do projeto e o nome de origem. O exemplo a seguir usa branch para resolver a versão padrão quando o pipeline é disparado manualmente ou agendado. A entrada da ramificação não pode ter curingas.

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

O exemplo a seguir mostra um recurso de pipeline com um gatilho simples.

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

O exemplo a seguir mostra um recurso de pipeline trigger com condições de ramificação.

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

O exemplo a seguir usa filtros stages para avaliar condições de gatilho para pipelines de CD. As etapas usam o operador AND. Após a conclusão bem-sucedida de todas as etapas fornecidas, o pipeline de CD é disparado.

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

O exemplo a seguir usa filtros tags para avaliação de versão padrão e para gatilhos. As tags usam o operador AND.

As tags são definidas no pipeline de CI (integração contínua) ou CD. Essas tags são diferentes das tags definidas nas ramificações no repositório Git.

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

Avaliação da versão do artefato de pipelines

A versão do artefato do pipeline de recursos depende de como o pipeline é disparado.

Gatilho manual ou programado

Se a execução do pipeline for disparada ou agendada manualmente, os valores das propriedades version, branch e tags definirão a versão do artefato. A entrada branch não pode ter curingas. As propriedades tags usam o operador AND.

A definição de recurso pipeline a seguir usa as propriedades branch e tags para avaliar a versão padrão quando o pipeline é disparado manualmente ou agendado. Quando você dispara manualmente o pipeline para execução, a versão dos artefatos do pipeline MyCIAlias é o build mais recente feito na ramificação main e que tem as tags Production e PrepProduction.

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

Gatilho de conclusão do pipeline de recursos

Quando um pipeline é disparado porque um dos pipelines de recurso foi concluído, a versão dos artefatos é a versão do pipeline de gatilho. Os valores das propriedades version, branch e tags são ignorados.

O pipeline a seguir é executado sempre que o pipeline de recursos SmartHotel-CI:

• É executado em uma das ramificações releases ou na ramificação main
• É marcado com Verified e Signed
• Conclui as fases Production e PreProduction

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

Download de artefato de pipeline

A etapa download baixa artefatos associados à execução atual ou a outro recurso de pipeline.

Todos os artefatos do pipeline atual e de todos os recursos pipeline são baixados e disponibilizados automaticamente no início de cada trabalho de implantação. Você pode substituir esse comportamento definindo download como none ou especificando outro identificador de recurso de pipeline.

Os artefatos de trabalho regulares não são baixados automaticamente. Use download explicitamente quando necessário.

Os artefatos do recurso pipeline são baixados para a pasta $(PIPELINE.WORKSPACE)/<pipeline-identifier>/<artifact-identifier>. Para obter mais informações, consulte Publicar e baixar artefatos de pipeline.

A propriedade opcional artifact especifica nomes de artefatos. Se não for especificado, todos os artefatos disponíveis serão baixados. A propriedade patterns opcional define padrões que representam arquivos a serem incluídos. Para obter informações completas sobre o esquema, consulte a definição steps.download.

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

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)

Definição de recurso de builds

Se você tiver um sistema de build de CI externo que produz artefatos, poderá consumir artefatos com recursos builds. Um recurso build pode ser de qualquer sistema de CI externo, como Jenkins, TeamCity ou CircleCI.

A categoria builds é extensível. Você pode gravar uma extensão para consumir artefatos do serviço de build e introduzir um novo tipo de serviço como parte do builds.

Na definição build, o padrão version é a compilação bem-sucedida mais recente. O trigger não está habilitado por padrão e deve ser definido explicitamente. Para obter informações completas sobre o esquema, consulte a definição resources.builds.build.

No exemplo a seguir, Jenkins é o recurso type.

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

A tarefa downloadBuild

Os artefatos do recurso build não são baixados automaticamente nos seus trabalhos/deploy-jobs. Para consumir artefatos do recurso build como parte de seus trabalhos, você precisa adicionar explicitamente a tarefa downloadBuild. Você pode personalizar o comportamento de download para cada implantação ou trabalho.

Essa tarefa é resolvida automaticamente para a tarefa de download correspondente do tipo de recurso build definido por runtime. Os artefatos do recurso build são baixados para a pasta $(PIPELINE.WORKSPACE)/<build-identifier>/.

Na definição downloadBuild, você especifica o recurso do qual fazer download de artefatos. A propriedade artifact opcional especifica artefatos a serem baixados. Se não for especificado, todos os artefatos associados ao recurso serão baixados.

A propriedade patterns opcional define um caminho de minicorrespondência ou uma lista de caminhos de minicorrespondência a serem baixados. Se estiver em branco, todo o artefato será baixado. Por exemplo, o snippet a seguir baixa apenas os arquivos *.zip.

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

Para obter informações completas sobre o esquema, consulte a definição steps.downloadBuild.

Definição de recurso do repositório

A palavra-chave repository permite especificar um repositório externo. Use esse recurso se o pipeline tiver modelos em outro repositório ou se você quiser usar o check-out de vários repositórios com um repositório que exija uma conexão de serviço. Você deve informar o sistema sobre esses repositórios.

Por exemplo:

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

Para obter informações completas sobre o esquema, consulte a definição resources.repositories.repository.

Tipos de recurso de repositório

O Azure Pipelines dá suporte aos seguintes valores para o tipo de repositório: git, github, githubenterprise e bitbucket.

• O tipo git refere-se aos repositórios Git do Azure Repos.
• Os repositórios GitHub Enterprise exigem uma conexão de serviço do GitHub Enterprise para autorização.
• Os repositórios Bitbucket Cloud exigem uma conexão de serviço do Bitbucket Cloud para autorização.

Variáveis de 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:
    - 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)"

Palavra-chave de checkout para repositórios

Os repositórios do recurso repository não são sincronizados automaticamente nos seus trabalhos. Use a palavra-chave checkout para buscar um repositório definido como parte do recurso repository. Para obter informações completas sobre o esquema, consulte a definição steps.checkout.

Para obter mais informações, confira Fazer check-out de vários repositórios no pipeline.

Definição de recurso de contêineres

Se você precisar consumir imagens de contêiner como parte de seus pipelines de CI/CD, poderá usar recursos containers. Um recurso container pode ser um registro do Docker público ou privado ou uma instância do Registro de Contêiner do Azure.

Você pode consumir uma imagem de recurso de contêiner genérico como parte do trabalho ou usar o recurso para trabalhos de contêiner. Se o pipeline exigir o suporte de um ou mais serviços, você precisará criar e se conectar a contêineres de serviço. É possível usar volumes para compartilhar dados entre serviços.

Se você precisar consumir imagens de um Registro do Docker como parte do pipeline, poderá definir um recurso de contêiner genérico. Nenhuma palavra-chave type é necessária. Por exemplo:

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

Para obter informações completas sobre o esquema, consulte a definição resources.containers.container.

Tipo de recurso do Registro de Contêiner do Azure

Para consumir suas imagens do Registro de Contêiner do Azure, você pode usar o tipo de recurso de contêiner de primeira classe acr. Use esse tipo de recurso como parte dos seus trabalhos e para habilitar gatilhos de pipeline automáticos.

Você precisa das permissões de Colaborador ou Proprietário para que o Registro de Contêiner do Azure use gatilhos de pipeline automáticos. Para obter mais informações, confira Funções e permissões do Registro de Contêiner do Azure.

Para usar o tipo de recurso acr, você deve especificar os valores azureSubscription, resourceGroup e repository para o registro de contêiner do Azure. Por exemplo:

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

Variáveis de recurso de contêiner

Depois de definir um contêiner como um recurso, os metadados de imagem de contêiner são transmitidos para o pipeline como variáveis. Informações como imagem, registro e detalhes de conexão podem ser acessadas em todos os trabalhos usados nas 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 local. A variável location se aplica somente ao tipo acr de recursos de contêiner.

O exemplo a seguir tem uma conexão de serviço do Azure Resource Manager chamada arm-connection. Para obter mais informações, confira Registros, repositórios e imagens de contêiner do Azure.

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

pool:
  vmImage: 'ubuntu-latest'

steps:
- getPackage: contoso

resources:
  webhooks:
    - webhook: WebHook
      connection: IncomingWH

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

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

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

Seletor de versão manual para recursos

Quando você dispara manualmente um pipeline de CD YAML, o Azure Pipelines avalia automaticamente as versões padrão para os recursos definidos no pipeline com base nas entradas fornecidas. No entanto, o Azure Pipelines considera apenas as execuções de CI concluídas com êxito, quando avalia a versão padrão para gatilhos agendados ou se você não escolhe uma versão manualmente.

Você pode usar o seletor de versão do recurso para escolher manualmente uma versão diferente ao criar uma execução. O seletor de versão do recurso tem suporte para recursos de pipeline, build, repositório, contêiner e pacote.

Para recursos de pipeline, você pode ver todas as execuções disponíveis em todas as ramificações, pesquisá-las com base no número ou ramificação do pipeline e escolher 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 uma execução produziu todos os artefatos necessários. Você não precisa esperar que uma execução de CI seja concluída ou executada novamente devido a uma falha de fase não relacionada.

Para usar o seletor de versão do recurso, no painel Executar pipeline, selecione Recursos, selecione um recurso e escolha uma versão específica na lista de versões disponíveis.

Para recursos em que você não pode buscar as versões disponíveis, como pacotes do GitHub, o seletor de versão fornece um campo de texto para que você possa inserir a versão para a execução escolher.

Autorização de recursos em pipelines YAML

Os recursos devem ser autorizados para que possam ser usados em pipelines. Os proprietários de recurso controlam os usuários e pipelines que podem acessar recursos. Há várias maneiras de autorizar um pipeline YAML a usar recursos.

• Use a experiência de administração de recursos para autorizar todos os pipelines a acessar o recurso. Por exemplo, grupos de variáveis e arquivos seguros são gerenciados na página Biblioteca em Pipelines, e pools de agentes e conexões de serviço são gerenciados nas Configurações do projeto. Essa autorização será conveniente se você não precisar restringir o acesso a recursos, como recursos de teste.

• Quando você cria um pipeline, todos os recursos referenciados no arquivo YAML são automaticamente autorizados para serem usados pelo pipeline, se você tiver a função Usuário para esses recursos.

• Se você adicionar um recurso a um arquivo YAML e a compilação falhar com um erro como Could not find a <resource> with name <resource-name>. The <resource> does not exist or has not been authorized for use., 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 e autorizar o recurso no build com falha. Depois que o recurso for autorizado, você poderá iniciar um novo build.

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

Verificações de aprovação para recursos

Você pode usar verificações de aprovação e modelos para controlar manualmente quando um recurso é executado. Com a verificação de aprovação de modelo necessária, você pode exigir qualquer pipeline usando um recurso ou ambiente que se estenda a partir de um modelo YAML específico.

Definir uma aprovação de modelo necessária garante que seu recurso seja usado somente em condições específicas e aumenta a segurança. Para saber mais sobre como aprimorar a segurança do pipeline com modelos, consulte Usar modelos para segurança.

Rastreabilidade

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

Rastreabilidade de pipeline

O Azure Pipelines mostra as seguintes informações para cada execução de pipeline:

• Se um recurso disparou o pipeline, o recurso que disparou o pipeline.
• A versão do recurso e os artefatos consumidos.
• Confirmações associadas a cada recurso.
• 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 consumidos. A exibição inclui os recursos consumidos como parte dos trabalhos de implantação e as confirmações e itens de trabalho associados.

Informações de pipelines de CD associados em pipelines de CI

Para fornecer rastreabilidade completa, você pode acompanhar quais pipelines de CD consomem um pipeline de CI específico por meio do recurso pipelines. Se outros pipelines consumirem seu pipeline de CI, você verá uma guia Pipelines associados na exibição Executar. A exibição mostra todas as execuções de pipeline YAML de CD que consumiram seu pipeline de CI e os artefatos dele.

Problemas de gatilho de recursos

Os gatilhos de recursos podem falhar ao serem executados porque:

• A origem da conexão de serviço fornecida for inválida, houver erros de sintaxe no gatilho ou o gatilho não será configurado.
• As condições de gatilho não são correspondidas.

Para ver por que os gatilhos de pipeline não foram executados, selecione o item de menu Problemas de gatilho na página de definição de pipeline. O item de menu Problemas de gatilho só está disponível para recursos não relacionados ao repositório.

Na página Problemas de gatilho, as mensagens de erro e aviso descrevem por que o gatilho falhou.

Perguntas frequentes

Quando devo usar recursos de pipelines, o atalho de download ou a tarefa Baixar Artefatos de Pipeline?

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

Você pode usar o atalho download para baixar os artefatos em trabalhos de build ou substituir o comportamento de download em trabalhos de implantação. Para obter mais informações, consulte a definição steps.download.

A tarefa Baixar Artefatos de Pipeline não fornece rastreabilidade ou gatilhos, mas às vezes faz sentido usar essa tarefa diretamente. Por exemplo, você pode ter uma tarefa de script armazenada em um modelo diferente que requer que artefatos de um build sejam baixados. Ou talvez você não queira adicionar um recurso de pipeline a um modelo. Para evitar dependências, você pode usar a tarefa Baixar Artefatos de Pipeline para passar todas as informações de build para uma tarefa.

Como posso disparar uma execução de pipeline, quando minha imagem do Docker Hub for atualizada?

O gatilho de recurso de contêineres não está disponível para Docker Hub para pipelines YAML, então você precisará configurar um pipeline de lançamento clássico.

1. Crie uma nova conexão de serviço do Docker Hub.
2. Crie um pipeline de lançamento clássico e adicione um artefato do Docker Hub. Defina sua conexão de serviço e selecione o namespace, o repositório, a versão e o alias de origem.
3. Selecione o gatilho e alterne o gatilho de implantação contínua para Habilitar. Todo push do Docker que ocorre no repositório selecionado cria uma versão.
4. Crie uma nova fase e um trabalho. Adicione duas tarefas, logon do Docker e Bash.
   • A tarefa do Docker tem a ação login e registra você no Docker Hub.
   • A tarefa Bash executa docker pull <hub-user>/<repo-name>[:<tag>].

Como posso validar e solucionar problemas com meu webhook?

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

2. Referencie sua conexão de serviço e nomeie o webhook na seção webhooks.

   resources:
     webhooks:
       - webhook: MyWebhookTriggerAlias
         connection: MyServiceConnection
   

3. Executar o pipeline. O webhook é criado no Azure como uma tarefa distribuída para sua organização.

4. Execute uma chamada à API POST com o 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, o webhook estará pronto para ser consumido pelo 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 um branch que não seja o branch padrão. Para resolver esse problema:

1. Selecione Editar em sua página pipeline.
2. No menu Mais ações, selecione Gatilhos.
3. Selecione a guia YAML e, em seguida, Obter fontes.
4. Em Branch padrão para builds manuais e agendados, atualize a ramificação de recurso.
5. Selecione Salvar e colocar na fila.
6. Depois que esse pipeline for executado com êxito, execute uma chamada à API POST com o 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.

Conteúdo relacionado

• Sobre os recursos do Azure Pipelines
• Definir variáveis
• Adicionar e usar grupos de variáveis
• Criar e direcionar um ambiente
• Usar editor de pipeline YAML
• Referência de esquema YAML