Confira vários repositórios em seu pipeline

Artigo
02/28/2024

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.

Azure Repos Git (git)

Azure DevOps Server (limitado a repositórios na mesma organização)
Serviços de DevOps do Azure

GitHub (github)

Serviços de DevOps do Azure

GitHubEnterprise (githubenterprise)

Serviços de DevOps do Azure

Nuvem Bitbucket (bitbucket)

Serviços de DevOps do Azure

Importante

Somente repositórios do Azure Repos Git (git) na mesma organização que o pipeline têm suporte para check-out de vários repositórios no Servidor de DevOps do Azure.

Nota

O Azure Pipelines fornece configurações de escopo de trabalho de Limite para repositórios Git do Azure Repos. Para fazer check-out dos repositórios Git do Azure Repos hospedados em outro projeto, o escopo do trabalho Limitar deve ser configurado para permitir o acesso. Para obter mais informações, consulte Limitar o escopo de autorização de trabalho.

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

Sem checkout passos

O comportamento padrão é como se checkout: self fosse a primeira etapa, e o repositório atual é submetido a check-out.

Um único checkout: none passo

Nenhum repositório é sincronizado ou submetido a check-out.

Um único checkout: self passo

Foi feito check-out do repositório atual.

Um único checkout passo que não self é ou none

O repositório designado é submetido a check-out em vez de self.

Várias checkout etapas

Cada repositório designado é submetido a check-out em uma pasta com o nome do repositório, a menos que um diferente path seja especificado na checkout etapa. Para fazer check-out self como um dos repositórios, use checkout: self como uma das checkout etapas.

Nota

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. Para obter mais informações, consulte Por que sou solicitado a autorizar recursos na primeira vez que tento fazer check-out de um repositório diferente? na seção Perguntas frequentes .

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.

Tipo de repositório	Conexão de serviço
Nuvem Bitbucket	Nuvem Bitbucket
GitHub	GitHub
GitHub Enterprise Server	Servidor GitHub Enterprise
Repositórios Git do Azure Repos em uma organização diferente do seu pipeline	Azure Repos/Team Foundation Server

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.

Nota

Somente repositórios Git do Azure Repos na mesma organização podem usar a sintaxe embutida. Os repositórios Git do Azure Repos em uma organização diferente e outros tipos de repositório com suporte exigem uma conexão de serviço e devem ser declarados como um recurso de repositório.

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

Nota

No exemplo anterior, o self repositório de check-out é especificado para fazer checkout da origem do repositório associado ao pipeline.

Se você estiver usando o repositório Git do Azure Repos padrão (que tem o mesmo nome do projeto), use o formato - checkout: git://MyProject/MyRepo.

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

Nota

Se você estiver usando caminhos padrão, adicionar uma segunda etapa do repositório checkout alterará o caminho padrão do código para o primeiro repositório. Por exemplo, o código de um repositório nomeado tools seria verificado para C:\agent\_work\1\s quando tools é o único repositório, mas se um segundo repositório for adicionado, tools será feito check-out para C:\agent\_work\1\s\tools. Se você tiver alguma etapa que dependa do código-fonte estar no local original, essa etapa deverá ser atualizada.

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

Acionadores

Você pode acionar um pipeline quando uma atualização é enviada por push para o self repositório ou para qualquer um dos repositórios declarados como recursos. Isso é útil, por exemplo, nos seguintes cenários:

Você consome uma ferramenta ou uma biblioteca de um repositório diferente. Você deseja executar testes para seu aplicativo sempre que a ferramenta ou biblioteca for atualizada.
Você mantém seu arquivo YAML em um repositório separado do código do aplicativo. Você deseja acionar o pipeline sempre que uma atualização for enviada por push para o repositório do aplicativo.

Importante

Os gatilhos de recursos de repositório só funcionam para repositórios Git do Azure Repos na mesma organização e quando o self tipo de repositório é o Azure Repos Git. Eles não funcionam para recursos de repositório GitHub ou Bitbucket.

batch não é suportado em gatilhos de recursos do repositório.

Se você não especificar uma trigger seção em um recurso de repositório, o pipeline não será acionado por alterações nesse repositório. Se você especificar uma trigger seção, o comportamento para acionamento será semelhante ao funcionamento dos gatilhos de CI para o repositório automático.

Se você especificar uma trigger seção para vários recursos do repositório, uma alteração em qualquer um deles iniciará uma nova execução.

Quando um pipeline é acionado, o Azure Pipelines precisa determinar a versão do arquivo YAML que deve ser usada e uma versão para cada repositório que deve ser verificada. Se uma alteração no self repositório acionar um pipeline, a confirmação que disparou o pipeline será usada para determinar a versão do arquivo YAML. Se uma alteração em qualquer outro recurso de repositório acionar o pipeline, a versão mais recente do YAML da ramificação padrão do self repositório será usada.

Quando uma atualização para um dos repositórios aciona um pipeline, as seguintes variáveis são definidas com base no repositório de acionamento:

Build.Repository.ID
Build.Repository.Name
Build.Repository.Provider
Build.Repository.Uri
Build.SourceBranch
Build.SourceBranchName
Build.SourceVersion
Build.SourceVersionMessage

Para o repositório de acionamento, a confirmação que disparou o pipeline determina a versão do código com check-out. Para outros repositórios, o ref definido no YAML para esse recurso de repositório determina a versão padrão com check-out.

Considere o exemplo a seguir, onde o self repositório contém o arquivo YAML e repositórios A e B contém código-fonte adicional.

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

A tabela a seguir mostra quais versões são verificadas para cada repositório por um pipeline usando o arquivo YAML acima.

Alteração feita para	Pipeline acionado	Versão do YAML	Versão do `self`	Versão do `A`	Versão do `B`
`main` no `self`	Sim	commit a partir `main` disso acionou o pipeline	commit a partir `main` disso acionou o pipeline	mais recente de `main`	mais recente de `release`
`feature` no `self`	Sim	commit a partir `feature` disso acionou o pipeline	commit a partir `feature` disso acionou o pipeline	mais recente de `main`	mais recente de `release`
`main` no `A`	Sim	mais recente de `main`	mais recente de `main`	commit a partir `main` disso acionou o pipeline	mais recente de `release`
`main` no `B`	Sim	mais recente de `main`	mais recente de `main`	mais recente de `main`	commit a partir `main` disso acionou o pipeline
`release` no `B`	Sim	mais recente de `main`	mais recente de `main`	mais recente de `main`	commit a partir `release` disso acionou o pipeline

Você também pode acionar o pipeline ao criar ou atualizar uma solicitação pull em qualquer um dos repositórios. Para fazer isso, declare os recursos do repositório nos arquivos YAML como nos exemplos acima e configure uma política de ramificação no repositório (somente Repositórios do Azure).

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.

Esse pipeline precisa de permissão para acessar um recurso