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

Azure DevOps Services | Azure Servidor DevOps | Azure DevOps Server 2022

Pipelines geralmente dependem de vários repositórios que contêm código-fonte, ferramentas, scripts ou outros itens necessários para criar 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 repositório ou embutido 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 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 Azure Repos em outra organizaçãoGitHub e Bitbucket Cloud recursos de repositório exigem conexões service, 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).

Repositório de workspace

Quando várias etapas de checkout (e caminhos diferentes para cada) são usadas em seu pipeline, talvez você queira usar o diretório raiz de um dos repositórios como o diretório de trabalho padrão. Nesse caso, você pode definir a entrada workspaceRepo como true para a etapa de checkout relacionada.

- checkout: git://project/first
  path: repo/first-repo

- checkout: git://project/second
  path: repo/second-repo
  workspaceRepo: true

- pwsh: pwd
# Expected output: $(Pipeline.Workspace)/repo/second-repo

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.

Parametrizar ramificação com sintaxe embutida

Defina um parâmetro de runtime e faça referência a ele com uma expressão de modelo no valor de check-out embutido:

parameters:
  - name: branch
    type: string
    default: 'main'

steps:
  - checkout: git://MyProject/MyRepo@${{ parameters.branch }}

Parametrizar branch com um recurso de repositório

Use a ref propriedade em um recurso de repositório para definir o branch de um parâmetro:

parameters:
  - name: branch
    type: string
    default: 'main'

resources:
  repositories:
    - repository: MyRepo
      type: git
      name: MyProject/MyRepo
      ref: ${{ parameters.branch }}

steps:
  - checkout: MyRepo

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 tags para verificar a 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ê 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 outra project? 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 outra project? Costumava funcionar.

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

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

Ao fazer check-out Azure Repos repositórios Git diferentes daquele que contém o pipeline, talvez você seja solicitado a autorizar access para 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.