Consulte varios repositorios en la canalización.

Se admiten las siguientes checkout combinaciones de pasos.

Definición de recursos del repositorio

Debe usar un recurso de repositorio si el tipo de repositorio requiere una conexión de servicio u otros recursos extendidos. Los siguientes tipos de repositorio requieren una conexión de servicio.

Puede usar un recurso de repositorio incluso si el tipo de repositorio no requiere una conexión de servicio, por ejemplo, si tiene un recurso de repositorio definido ya para las plantillas de un repositorio diferente.

En el ejemplo siguiente, tres repositorios se declaran como recursos de repositorio. El Azure Repos de Gitde otra organización, GitHuby los recursos del repositorio en la nube de Bitbucket requieren conexiones de servicio ,que se especifican como para esos recursos de repositorio. Este ejemplo tiene cuatro pasos, que comprueban los tres repositorios declarados como recursos de repositorio junto con el repositorio actual que contiene la checkoutself canalización 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)

Si el self repositorio se denomina , el comando genera la siguiente CurrentReposcript salida: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo . En este ejemplo, los nombres de los repositorios se usan para las carpetas, porque no se especifica ningún path en el paso de desprotección. Para más información sobre los nombres y ubicaciones de las carpetas del repositorio, consulte la siguiente sección Ruta de acceso de finalización de la compra.

Desprotección de sintaxis inserta

Si el repositorio no requiere una conexión de servicio, puede declararlo en línea con el checkout paso.

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

Ruta de finalización de la compra

A menos path que se especifique un en el checkout paso, el código fuente se coloca en un directorio predeterminado. Este directorio es diferente en función de si está des check out a single repository or multiple repositories.

• Repositorio único:si tiene un solo paso en el trabajo o no tiene ningún paso de desprotección equivalente a , el código fuente se desproteme en un directorio denominado ubicado como una subcarpeta de checkout: selfs(Agent.BuildDirectory) . Si (Agent.BuildDirectory) es , el código se C:\agent\_work\1 desprotetee en C:\agent\_work\1\s .

• Varios repositorios:si tiene varios pasos en el trabajo, el código fuente se desprotee en directorios denominados después de los repositorios como una subcarpeta de en s(Agent.BuildDirectory) . Si (Agent.BuildDirectory) es y los C:\agent\_work\1 repositorios se denominan tools y , el código se code desprotee y C:\agent\_work\1\s\toolsC:\agent\_work\1\s\code .

  Nota

  Si no se especifica ningún en el paso, se usa el nombre del repositorio para la carpeta, no el valor que se usa para hacer referencia al repositorio pathcheckout en el repositorycheckout paso.

Si se path especifica para un checkout paso, se usa esa ruta de acceso, en relación con (Agent.BuildDirectory) .

Comprobación de una referencia específica

La rama predeterminada se desprotee, a menos que designe una referencia específica.

Si usa la sintaxis insertada, designe la referencia anexando @<ref> . Por ejemplo:

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

Cuando use un recurso de repositorio, especifique la referencia mediante la ref propiedad . En el ejemplo siguiente se comprueba features/tools/ la rama del repositorio designado.

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

steps:
- checkout: MyGitHubRepo

trigger:
- main

steps:
...

resources:
  repositories:
  - repository: self
    type: git
    name: MyProject/MyGitRepo
    trigger:
    - main

steps:
...

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

Detalles del repositorio

Al consultar varios repositorios, algunos detalles sobre self el repositorio están disponibles como self. Cuando se usan desencadenadores de varios repositorios, algunas de esas variables tienen información sobre el repositorio de desencadenadores en su lugar. Los detalles sobre todos los repositorios consumidos por el trabajo están disponibles como un objeto de contexto de plantilla denominado .

Por ejemplo, para obtener la referencia de un repositorio que no es self de , podría escribir una canalización como esta:

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"

Preguntas más frecuentes

• ¿Por qué no puedo consultar un repositorio de otro proyecto? Se utiliza para trabajar.
• ¿Por qué se me pide que autorice los recursos la primera vez que intento consultar un repositorio diferente?

¿Por qué no puedo consultar un repositorio de otro proyecto? Se utiliza para trabajar.

Azure Pipelines proporciona una configuración Limitar el ámbito de autorización del trabajo al proyecto actual, que cuando está habilitada, no permite que la canalización acceda a recursos fuera del proyecto que contiene la canalización. Esta configuración se puede establecer en el nivel de organización o de proyecto. Si esta configuración está habilitada, no podrá consultar un repositorio en otro proyecto a menos que conceda acceso explícitamente. Para obtener más información, vea Ámbito de autorización de trabajos.

¿Por qué se me pide que autorice los recursos la primera vez que intento consultar un repositorio diferente?

Al consultar Azure Repos repositorios de Git distintos del que contiene la canalización, es posible que se le pida que autorice el acceso a ese recurso antes de que la canalización se ejecute por primera vez. Estos avisos se muestran en la página de resumen de ejecución de canalización.

Elija Ver o Autorizar recursosy siga las indicaciones para autorizar los recursos.

Para obtener más información, vea Solución de problemas de autorización para una canalización de YAML.

Azure Pipelines | Azure DevOps Server 2020

Pipelines a menudo se basan en varios repositorios que contienen código fuente, herramientas, scripts u otros elementos que necesita para compilar el código. Mediante el uso de varios pasos en la canalización, puede capturar y consultar otros repositorios además del que checkout se usa para almacenar la canalización de YAML.

Especificar varios repositorios

Los repositorios se pueden especificar como un recurso de repositorioo en línea con el paso .

Se admiten los siguientes tipos de repositorio.