Fazer check-out de vários repositórios em seu pipeline

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

Os pipelines geralmente dependem de vários repositórios que contêm código-fonte, ferramentas, scripts ou outros itens necessários para compilar seu código. Usando várias etapas checkout em seu pipeline, você pode buscar e fazer check-out de outros repositórios além daquele que você usa para armazenar seu pipeline YAML.

Especificar vários repositórios

Os repositórios podem ser especificados como um recurso de repositório ou em linha com a etapa checkout.

Há suporte para os tipos de repositório a seguir.

Há suporte para as combinações de etapas checkout a seguir.

Definição de recurso do repositório

Você deve usar um recurso de repositório se o tipo de repositório exigir uma conexão de serviço ou outro campo de recursos estendidos. Os seguintes tipos de repositório exigem uma conexão de serviço.

Você pode usar um recurso de repositório mesmo que seu tipo de repositório não exija uma conexão de serviço, por exemplo, se você tiver um recurso de repositório definido para modelos em um repositório diferente.

No exemplo a seguir, três repositórios são declarados como recursos do repositório. O repositório Git do Azure Repos em outra organização, o GitHub e os recursos do repositório Bitbucket Cloud exigem conexões de serviço, que são especificadas como endpoint para esses recursos de repositório. Este exemplo tem quatro etapas checkout, que verifica os três repositórios declarados como recursos de repositório junto com o repositório self atual que contém o YAML do pipeline.

resources:
  repositories:
  - repository: MyGitHubRepo # The name used to reference this repository in the checkout step
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
  - repository: MyBitbucketRepo
    type: bitbucket
    endpoint: MyBitbucketServiceConnection
    name: MyBitbucketOrgOrUser/MyBitbucketRepo
  - repository: MyAzureReposGitRepository # In a different organization
    endpoint: MyAzureReposGitServiceConnection
    type: git
    name: OtherProject/MyAzureReposGitRepo

trigger:
- main

pool:
  vmImage: 'ubuntu-latest'

steps:
- checkout: self
- checkout: MyGitHubRepo
- checkout: MyBitbucketRepo
- checkout: MyAzureReposGitRepository

- script: dir $(Build.SourcesDirectory)

Se o repositório self for chamado de CurrentRepo, o comando script produzirá a seguinte saída: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. Neste exemplo, os nomes dos repositórios (conforme especificado pela propriedade name no recurso de repositório) são usados para as pastas porque nenhum path é especificado na etapa de verificação. Para obter mais informações sobre os nomes e locais das pastas do repositório, confira a seção Caminho do check-out a seguir.

Check-out de sintaxe embutida

Se o repositório não exigir uma conexão de serviço, você poderá declará-lo embutido com a etapa checkout.

steps:
- checkout: self
- checkout: git://MyProject/MyRepo # Azure Repos Git repository in the same organization

Caminho do check-out

A menos que um path seja especificado na etapa checkout, o código-fonte é colocado em um diretório padrão. Esse diretório é diferente dependendo se você está fazendo check-out de um ou vários repositórios.

• Repositório único: se você tiver uma única etapa checkout em seu trabalho ou não tiver nenhuma etapa de check-out equivalente a checkout: self, o check-out será feito no código-fonte em um diretório chamado s localizado como uma subpasta de (Agent.BuildDirectory). Se (Agent.BuildDirectory) for C:\agent\_work\1, o check-out será feito no código para C:\agent\_work\1\s.

• Vários repositórios: se você tiver várias etapas checkout em seu trabalho, o check-out será feito no código-fonte em diretórios nomeados com base nos repositórios como uma subpasta do s em (Agent.BuildDirectory). Se (Agent.BuildDirectory) for C:\agent\_work\1 e seus repositórios forem nomeados tools e code, o check-out será feito no código em C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

  Observação

  Se nenhum path for especificado na etapa checkout, o nome do repositório será usado para a pasta, não o valor repository usado para fazer referência ao repositório na etapa checkout.

Se um path for especificado para uma etapa checkout, esse caminho será usado em relação a (Agent.BuildDirectory).

Como fazer check-out de uma referência específica

O branch padrão é verificado, a menos que você escolha uma ref. específica.

Se você estiver usando a sintaxe embutida, designe a referência acrescentando @<ref>. Por exemplo:

- checkout: git://MyProject/MyRepo@features/tools # checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/heads/features/tools # also checks out the features/tools branch
- checkout: git://MyProject/MyRepo@refs/tags/MyTag # checks out the commit referenced by MyTag.

Ao usar um recurso de repositório, especifique a referência usando a propriedade ref. O exemplo a seguir faz check-out do branch features/tools/ do repositório designado.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: features/tools

steps:
- checkout: MyGitHubRepo

O exemplo a seguir usa marcas para fazer check-out do commit referenciado por MyTag.

resources:
  repositories:
  - repository: MyGitHubRepo
    type: github
    endpoint: MyGitHubServiceConnection
    name: MyGitHubOrgOrUser/MyGitHubRepo
    ref: refs/tags/MyTag

steps:
- checkout: MyGitHubRepo

trigger:
- main
- feature

resources:
  repositories:
  - repository: A
    type: git
    name: MyProject/A
    ref: main
    trigger:
    - main

  - repository: B
    type: git
    name: MyProject/B
    ref: release
    trigger:
    - main
    - release
steps:
- checkout: self
- checkout: A
- checkout: B

Detalhes do repositório

Quando você fizer check-out em vários repositórios, alguns detalhes sobre o repositório self ficam disponíveis como variáveis. Quando você usa gatilhos de vários repositórios, algumas dessas variáveis têm informações sobre o repositório de gatilho. Detalhes sobre todos os repositórios consumidos pelo trabalho estão disponíveis como um objeto de contexto de modelo chamado resources.repositories.

Por exemplo, para obter a referência de um repositório não self, você pode gravar um pipeline como este:

resources:
  repositories:
  - repository: other
    type: git
    name: MyProject/OtherTools

variables:
  tools.ref: $[ resources.repositories['other'].ref ]

steps:
- checkout: self
- checkout: other
- bash: |
    echo "Tools version: $TOOLS_REF"

Perguntas frequentes

• Por que não consigo fazer check-out de um repositório de outro projeto? Costumava funcionar.
• Por que sou solicitado a autorizar recursos na primeira vez que tento fazer check-out de um repositório diferente?

Por que não consigo fazer check-out de um repositório de outro projeto? Costumava funcionar.

O Azure Pipelines fornece a opção Limitar escopo da autorização do trabalho para a configuração atual do projeto, que, quando habilitado, não permite que o pipeline acesse recursos fora do projeto que contém o pipeline. Essa configuração pode ser definida no nível da organização ou do projeto. Se essa configuração estiver habilitada, você não poderá fazer check-out de um repositório em outro projeto, a menos que conceda acesso explicitamente. Para obter mais informações, confira Escopo da autorização do trabalho.

Por que sou solicitado a autorizar recursos na primeira vez que tento fazer check-out de um repositório diferente?

Ao fazer check-out de repositórios Git do Azure Repos diferentes daquele que contém o pipeline, você pode ser solicitado a autorizar o acesso a esse recurso antes que o pipeline seja executado pela primeira vez. Esses prompts são exibidos na página de resumo da execução do pipeline.

Escolha Exibir ou Autorizar recursos e siga os prompts para autorizar os recursos.

Para obter mais informações, confira Solução de problemas de autorização para um pipeline YAML.