Confira vários repositórios em seu pipeline

Serviços de DevOps do Azure | Azure DevOps Server 2022 | Azure DevOps Server 2020

Muitas vezes, os pipelines dependem de vários repositórios que contêm origens, ferramentas, scripts ou outros itens de que precisa para compilar o seu código. Usando várias checkout etapas em seu pipeline, você pode buscar e verificar 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 checkout etapa.

Os seguintes tipos de repositório são suportados.

As seguintes combinações de etapas são suportadas checkout .

Definição de recursos 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ê já 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 de 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 para endpoint esses recursos de repositório. Este exemplo tem quatro checkout etapas, que verificam os três repositórios declarados como recursos de repositório junto com o repositório atual self que contém o pipeline YAML.

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 self repositório for nomeado CurrentRepo, o comando produzirá script a seguinte saída: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. Neste exemplo, os nomes dos repositórios (conforme especificado pela name propriedade no recurso de repositório) são usados para as pastas, porque nenhum path é especificado na etapa de checkout. Para obter mais informações sobre nomes e locais de pastas do repositório, consulte a seção Caminho de 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 em linha com sua checkout etapa.

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

Caminho de check-out

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

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

• Vários repositórios: Se você tiver várias checkout etapas em seu trabalho, o código-fonte será verificado em diretórios nomeados após os repositórios como uma subpasta de s in (Agent.BuildDirectory). Se (Agent.BuildDirectory) é C:\agent\_work\1 e seus repositórios são nomeados tools e code, seu código é verificado para C:\agent\_work\1\s\tools e C:\agent\_work\1\s\code.

  Nota

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

Se a path for especificado para uma checkout etapa, esse caminho será usado, relativo a (Agent.BuildDirectory).

Verificando uma ref específica

O check-out da ramificação padrão é feito a menos que você designe uma ref específica.

Se você estiver usando sintaxe embutida, designe a ref anexando @<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 recusa usando a ref propriedade. O exemplo a seguir faz check-out da features/tools/ ramificação 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 tags para fazer check-out da confirmação referenciada 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ê faz check-out de vários repositórios, alguns detalhes sobre o self repositório estão disponíveis como variáveis. Quando você usa gatilhos multi-repo, algumas dessas variáveis têm informações sobre o repositório de acionamento. Os 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 ref de um não-repositórioself , você pode escrever 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"

FAQ

• 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 disponibiliza um Âmbito de autorização de tarefas limite para a definição do projeto atual, que, quando está ativada, não permite que o pipeline aceda a recursos fora do projeto que contém o pipeline. Esta definição pode ser definida ao nível da organização ou do projeto. Se esta definição estiver ativada, não poderá dar saída de um repositório noutro projeto, a menos que conceda explicitamente o acesso. Para obter mais informações, veja Âmbito de autorização de tarefas.

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

Quando dá saída de repositórios Git do Azure Repos que não sejam o repositório que contém o pipeline, poderá ser-lhe pedido que autorize o acesso a esse recurso antes de o pipeline ser executado pela primeira vez. Estes pedidos são apresentados na página de resumo da execução do pipeline.

Escolha Exibir ou Autorizar recursos e siga as instruções para autorizar os recursos.

Para obter mais informações, veja Resolução de problemas de autorização de um pipeline YAML.