Extracción de repositorios múltiples en la canalización

Artículo
06/15/2023

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

Las canalizaciones suelen basarse en varios repositorios que contienen código fuente, herramientas, scripts u otros elementos que necesita para compilar código. Mediante el uso de varios pasos checkout en la canalización, es posible capturar y restaurar otros repositorios, además del que se usa para almacenar la canalización de YAML.

Especificación de repositorios múltiples

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

Se admiten los siguientes tipos de repositorio.

Azure Repos Git (git)

Azure DevOps Server (limitado a los repositorios de la misma organización)
Azure DevOps Services

GitHub (github)

Azure DevOps Services

GitHubEnterprise (githubenterprise)

Azure DevOps Services

Bitbucket Cloud (bitbucket)

Azure DevOps Services

Importante

Solo se admiten Azure Repos Git (git) en la misma organización que la canalización para la restauración de varios repositorios en Azure DevOps Server.

Nota:

Azure Pipelines proporciona la configuración Limitar el ámbito del trabajo para repositorios de Azure Repos Git. Para restaurar repositorios de Azure Repos Git hospedados en otro proyecto, se debe configurar Limitar el ámbito del trabajo para permitir el acceso. Para obtener más información, consulte Limitar el ámbito de autorización de trabajos.

Se admiten las siguientes combinaciones de pasos checkout.

Sin pasos checkout

El comportamiento predeterminado es como si checkout: self fuera el primer paso y el repositorio actual está restaurado.

Un solo paso checkout: none

No hay repositorios sincronizados ni restaurados.

Un solo paso checkout: self

El repositorio actual está restaurado.

Un solo paso checkout que no es self o none

El repositorio designado está restaurado en lugar de self.

Varios pasos checkout

Cada repositorio designado se restaura en una carpeta denominada igual que el repositorio, a menos que se especifique otro path en el paso checkout. Para restaurar self como uno de los repositorios, use checkout: self como uno de los pasos checkout.

Nota:

Al restaurar repositorios de Git de Azure Repos distintos de los que contienen 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. Para obtener más información, consulte ¿Por qué se me pide que autorice los recursos la primera vez que intento restaurar un repositorio distinto? en la sección de preguntas más frecuentes.

Definición de recursos del repositorio

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

Tipo de repositorio	Conexión de servicio
BitBucket Cloud	BitBucket Cloud
GitHub	GitHub
Servidor de GitHub Enterprise	Servidor de GitHub Enterprise
Los repositorios de Azure Repos Git en una organización diferente de la canalización	Azure Repos o Team Foundation Server

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

En el ejemplo siguiente, tres repositorios se declaran como recursos de repositorio. El repositorio de Azure Repos Git en otra organización, GitHub y los recursos del repositorio de Bitbucket Cloud requieren conexiones de servicio, que se especifican como endpoint para esos recursos del repositorio. Este ejemplo tiene cuatro pasos checkout, que restaura los tres repositorios declarados como recursos de repositorio junto con el repositorio actual self que contiene la canalización de 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 repositorio self se denomina CurrentRepo, el comando script genera la siguiente salida: CurrentRepo MyAzureReposGitRepo MyBitbucketRepo MyGitHubRepo. En este ejemplo, los nombres de los repositorios (según lo especificado por la propiedad name en el recurso del repositorio) se usan para las carpetas porque no se especifica ningún path en el paso de restauración. Para obtener más información sobre los nombres y las ubicaciones de las carpetas del repositorio, consulte la siguiente sección Ruta de acceso de restauración.

Restauración de sintaxis insertada

Si el repositorio no requiere una conexión de servicio, puede declararlo insertado con el paso checkout.

Nota:

Solo repositorios de Azure Repos de Git de la misma organización pueden usar la sintaxis insertada. Repositorios de Azure Repos Git en otra organización y otros tipos de repositorio admitidos requieren una conexión de servicio y deben declararse como un recurso de repositorio.

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

Nota:

En el ejemplo anterior, se especifica el repositorio de desprotección self para desproteger el origen del repositorio asociado a la canalización.

Si usa el repositorio de Git predeterminado de Azure Repos (que tiene el mismo nombre que el proyecto), use el formato - checkout: git://MyRepo/MyRepo.

Ruta de acceso de restauración

A menos que se especifique un elemento path en el paso checkout, el código fuente se coloca en un directorio predeterminado. Este directorio es diferente en función de si se restaura un único repositorio o varios.

Repositorio único: si tiene un solo paso checkout en el trabajo o no tiene ningún paso de restauración equivalente a checkout: self, el código fuente se restaura en un directorio denominado s ubicado como una subcarpeta de (Agent.BuildDirectory). Si (Agent.BuildDirectory) es C:\agent\_work\1, el código se restaura en C:\agent\_work\1\s.
Varios repositorios: si tiene varios pasos checkout en el trabajo, el código fuente se restaura en directorios con el nombre de los repositorios como una subcarpeta de s en (Agent.BuildDirectory). Si (Agent.BuildDirectory) es C:\agent\_work\1 y los repositorios se denominan tools y code, el código se restaura en C:\agent\_work\1\s\tools y C:\agent\_work\1\s\code.

Nota:

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

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

Nota:

Si usa rutas de acceso predeterminadas, agregar un segundo paso checkout del repositorio cambia la ruta de acceso predeterminada del código para el primer repositorio. Por ejemplo, el código de un repositorio denominado tools se restauraría en C:\agent\_work\1\s cuando tools fuera el único repositorio, pero si se agrega un segundo repositorio, tools se restauraría en C:\agent\_work\1\s\tools. Si tiene algún paso que dependa del código fuente que se encuentra en la ubicación original, estos pasos deben actualizarse.

Restauración de una referencia específica

La rama predeterminada se restaura, 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.

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

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

steps:
- checkout: MyGitHubRepo

En el ejemplo siguiente se usan etiquetas para restaurar la confirmación a la que MyTag hace referencia.

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

steps:
- checkout: MyGitHubRepo

Desencadenadores

Puede desencadenar una canalización cuando se inserta una actualización en el repositorio self o en cualquiera de los repositorios declarados como recursos. Esto es útil, por ejemplo, en los siguientes escenarios:

Se consume una herramienta o una biblioteca de un repositorio diferente. Quiere ejecutar pruebas para la aplicación siempre que se actualice la herramienta o biblioteca.
El archivo YAML se mantiene en un repositorio independiente del código de la aplicación. Quiere desencadenar la canalización cada vez que se inserta una actualización en el repositorio de aplicaciones.

Importante

Los desencadenadores de recursos de repositorio solo funcionan para los repositorios de Git de Azure Repos de la misma organización y cuando el tipo de repositorio self es Git de Azure Repos. No funcionan con los recursos de repositorio de GitHub o Bitbucket.

batch no se admite en desencadenadores de recursos de repositorio.

Si no especifica una sección trigger en un recurso de repositorio, la canalización no se desencadenará mediante cambios en ese repositorio. Si especifica una sección trigger, el comportamiento para desencadenar es similar a cómo funcionan los desencadenadores de CI para el repositorio automático.

Si especifica una sección trigger para varios recursos de repositorio, cualquier cambio que les aplique iniciará una nueva ejecución.

Cuando se desencadena una canalización, Azure Pipelines tiene que determinar la versión del archivo YAML que se debe usar y una versión para cada repositorio que se debe restaurar. Si un cambio en el repositorio self desencadena una canalización, la confirmación que desencadenó la canalización se usa para determinar la versión del archivo YAML. Si un cambio en cualquier otro recurso de repositorio desencadena la canalización, se usa la versión más reciente de YAML de la rama predeterminada del repositorio self.

Cuando una actualización de uno de los repositorios desencadena una canalización, se establecen las siguientes variables en función del repositorio desencadenador:

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

Para el repositorio desencadenador, la confirmación que desencadenó la canalización determina la versión del código que se restauró. En el caso de otros repositorios, el ref definido en YAML para ese recurso de repositorio determina la versión predeterminada que se restauró.

Considere el ejemplo siguiente, donde el repositorio self contiene el archivo YAML y los repositorios A y B contienen código fuente 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

En la tabla siguiente se muestran las versiones desprotegidas para cada repositorio mediante una canalización mediante el archivo YAML anterior.

Cambio realizado en	Canalización desencadenada	Versión de YAML	Versión de `self`	Versión de `A`	Versión de `B`
`main` en `self`	Sí	confirmación a partir de `main` que desencadenó la canalización	confirmación a partir de `main` que desencadenó la canalización	el más reciente a partir de `main`	el más reciente a partir de `release`
`feature` en `self`	Sí	confirmación a partir de `feature` que desencadenó la canalización	confirmación a partir de `feature` que desencadenó la canalización	el más reciente a partir de `main`	el más reciente a partir de `release`
`main` en `A`	Sí	el más reciente a partir de `main`	el más reciente a partir de `main`	confirmación a partir de `main` que desencadenó la canalización	el más reciente a partir de `release`
`main` en `B`	Sí	el más reciente a partir de `main`	el más reciente a partir de `main`	el más reciente a partir de `main`	confirmación a partir de `main` que desencadenó la canalización
`release` en `B`	Sí	el más reciente a partir de `main`	el más reciente a partir de `main`	el más reciente a partir de `main`	confirmación a partir de `release` que desencadenó la canalización

También puede desencadenar la canalización al crear o actualizar una solicitud de incorporación de cambios en cualquiera de los repositorios. Para ello, declare los recursos del repositorio en los archivos YAML como en los ejemplos anteriores y configure una directiva de rama en el repositorio (solo Azure Repos).

Detalles del repositorio

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

Por ejemplo, para obtener la referencia de un repositorio que no sea de self, 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 restaurar un repositorio desde otro proyecto? Se utiliza para trabajar.
¿Por qué se me solicita que autorice los recursos la primera vez que intento restaurar un repositorio diferente?

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

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

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

Al restaurar repositorios de Git de Azure Repos distintos de los que contienen 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. Estas indicaciones se muestran en la página de resumen de ejecución de canalización.

This pipeline needs permission to access a resource