Opciones de canalización para repositorios GIT

  • Artículo
  • 18 minutos para leer

Azure Pipelines | Azure DevOps Server 2020 | Azure DevOps Server 2019 | TFS 2018 - TFS 2015

Nota:

En Microsoft Team Foundation Server (TFS) 2018 y versiones anteriores, las canalizaciones de compilación y versión se denominan definiciones, las ejecuciones se denominan compilaciones, las conexiones de servicio se denominan puntos de conexión de servicio, las fases se denominan entornos y los trabajos se denominan fases.

Al editar una canalización que usa un repositorio de Git (en un proyecto de Azure DevOps, GitHub, GitHub Enterprise Server, Bitbucket Cloud u otro repositorio de Git), tiene las siguientes opciones.

Característica Azure Pipelines TFS 2017.2 y superior TFS 2017 RTM TFS 2015.4 TFS 2015 RTM
Rama Sí Sí Sí Sí Sí
Clean Sí Sí Sí Sí Sí
Orígenes de etiquetas o etiquetas Project; Solo clásico Proyecto de equipo Proyecto de equipo Proyecto de equipo No
Estado de compilación del informe Sí Sí Sí No No
Submódulos de desprotección Sí Sí Sí Sí Sí
Desprotección de archivos de LFS Sí Sí Agentes de Linux y macOS Agentes de Linux y macOS Agentes de Linux y macOS
Clonación de un segundo repositorio Sí Sí Sí Sí Sí
No sincronizar orígenes Sí Sí No No No
Captura superficial Sí Sí Agentes de Linux y macOS Agentes de Linux y macOS Agentes de Linux y macOS

Nota:

Azure Pipelines, TFS 2017.2 y versiones más recientes: Haga clic en Configuración avanzada en la tarea Obtener orígenes para ver algunas de las opciones anteriores.

Rama

TFS 2017 RTM y TFS 2015:este campo se denomina Rama predeterminada.

Esta es la rama que quiere que sea la predeterminada al poner en cola manualmente esta compilación. Si establece un desencadenador programado para la compilación, esta es la rama de la que la compilación obtiene los orígenes más recientes. La rama predeterminada no tiene ningún peso cuando la compilación se desencadena mediante la integración continua (CI). Normalmente, establecerá que sea la misma que la rama predeterminada del repositorio (por ejemplo, "master").

Limpieza del repositorio local en el agente

Puede realizar diferentes formas de limpiar el directorio de trabajo del agente auto hospedado antes de que se ejecute una compilación.

En general, para un rendimiento más rápido de los agentes auto hospedados, no limpie el repositorio. En este caso, para obtener el mejor rendimiento, asegúrese de que también está compilando incrementalmente deshabilitando cualquier opción Limpiar de la tarea o herramienta que usa para compilar.

Si necesita limpiar el repositorio (por ejemplo, para evitar problemas causados por archivos residuales de una compilación anterior), las opciones son las siguientes.

Nota:

La limpieza no es eficaz si usa un agente hospedado por Microsoft, ya que cada vez se obtiene un nuevo agente. Al usar agentes auto hospedados, en función de cómo se configuren los grupos de agentes, puede obtener un nuevo agente para las ejecuciones de canalización posteriores (o fases o trabajos en la misma canalización), por lo que no limpiar no es una garantía de que las ejecuciones, trabajos o fases posteriores puedan acceder a las salidas de ejecuciones, trabajos o fases anteriores.

Nota:

Al usar agentes auto hospedados, en función de cómo se configuren los grupos de agentes, puede obtener un nuevo agente para las ejecuciones de canalización posteriores (o fases o trabajos en la misma canalización), por lo que no limpiar no es una garantía de que las ejecuciones, trabajos o fases posteriores puedan acceder a las salidas de ejecuciones, trabajos o fases anteriores. Puede usar Artefactos de compilación para compartir las salidas de una ejecución de canalización, una fase o un trabajo con ejecuciones, fases o trabajos posteriores.

Azure Pipelines, Azure DevOps Server 2019 y versiones más recientes

Hay varias opciones de limpieza diferentes disponibles para las canalizaciones de YAML.

  • El checkout paso tiene una clean opción. Cuando se establece en true , la canalización se ejecuta antes de capturar el execute git clean -ffdx && git reset --hard HEAD repositorio. Para obtener más información, vea Checkout.
  • La workspace configuración de tiene varias opciones de limpieza job (salidas, recursos, todas). Para obtener más información, vea Área de trabajo.
  • La interfaz de usuario de configuración de canalización tiene un valor Clean, que cuando se establece en true es equivalente a especificar para cada paso de la checkout canalización. Para configurar la opción Limpiar:

    1. Edite la canalización, elija ...y seleccione Desencadenadores.

      Editar desencadenadores.

    2. Seleccione YAML,Obtener orígenesy configure el valor de Limpieza deseado. El valor predeterminado es false.

      Configuración limpia.

Para invalidar la configuración limpia al ejecutar manualmente una canalización, puede usar parámetros en tiempo de ejecución. En el ejemplo siguiente, se usa un parámetro en tiempo de ejecución para configurar la opción de limpieza de desprotección.

parameters:
- name: clean
  displayName: Checkout clean
  type: boolean
  default: false
  values:
  - false
  - true

trigger:
- main

pool: FabrikamPool
#  vmImage: 'ubuntu-latest'

steps:
- checkout: self
  clean: ${{ parameters.clean }}

De forma predeterminada, se establece en , pero se puede invalidar al ejecutar manualmente la canalización activando la casilla Desprotección limpia que se agrega para el parámetro en tiempo cleanfalse de ejecución. clean

TFS 2017 RTM

Si selecciona True, la canalización de compilación realiza una deshacer los cambios. Si se producen errores, elimina el contenido de $(Build.SourcesDirectory) .

Si desea que el modificador Limpiar descrito anteriormente funcione de forma diferente, en la pestaña Variables, defina la variable y establezca su valor en:

  • all si desea eliminar , que es la carpeta de trabajo completa que contiene la carpeta sources, la carpeta de archivos binarios, la carpeta $(Agent.BuildDirectory) artifacts, y así sucesivamente.

  • source si desea eliminar $(Build.SourcesDirectory) .

  • binary Si desea eliminar $(Build.BinariesDirectory) .

TFS 2015.4

Si selecciona True, la canalización de compilación realiza una deshacer los cambios. Si se producen errores, elimina el contenido de $(Build.SourcesDirectory) .

Si desea que el modificador Limpiar descrito anteriormente funcione de forma diferente, en la pestaña Variables, defina la variable y establezca su valor en:

  • all si desea eliminar , que es la carpeta de trabajo completa que contiene la carpeta sources, la carpeta de archivos binarios, la carpeta $(Agent.BuildDirectory) artifacts, y así sucesivamente.

  • source si desea eliminar $(Build.SourcesDirectory) .

  • binary Si desea eliminar $(Build.BinariesDirectory) .

TFS 2015 RTM

Seleccione true para eliminar la carpeta del repositorio.

Si desea que el modificador Limpiar descrito anteriormente funcione de forma diferente, en la pestaña Variables, defina la variable y establezca su valor en:

  • all si desea eliminar , que es la carpeta de trabajo completa que contiene la carpeta sources, la carpeta de archivos binarios, la carpeta $(Agent.BuildDirectory) artifacts, y así sucesivamente.

  • source si desea eliminar $(Build.SourcesDirectory) .

  • binary Si desea eliminar $(Build.BinariesDirectory) .

Orígenes de etiquetas

Es posible que quiera etiquetar los archivos de código fuente para permitir que el equipo identifique fácilmente qué versión de cada archivo se incluye en la compilación completada. También tiene la opción de especificar si el código fuente debe etiquetarse para todas las compilaciones o solo para las compilaciones correctas.

Nota:

Esta característica solo se puede usar cuando el repositorio de origen de la compilación es un repositorio GitHub o un repositorio git o TFVC del proyecto.

En el formato Etiqueta, puede usar variables predefinidas y definidas por el usuario que tengan un ámbito de "Todos". Por ejemplo:

$(Build.DefinitionName)_$(Build.DefinitionVersion)_$(Build.BuildId)_$(Build.BuildNumber)_$(My.Variable)

Las cuatro primeras variables están predefinidas. My.Variable puede definirlo usted en la My.Variable.

La canalización de compilación etiqueta los orígenes con una etiqueta git.

Algunas variables de compilación pueden producir un valor que no es una etiqueta válida. Por ejemplo, variables como $(Build.RequestedFor) y pueden contener espacios en $(Build.DefinitionName) blanco. Si el valor contiene espacios en blanco, no se crea la etiqueta.

Una vez que la canalización de compilación etiqueta los orígenes, se agrega automáticamente un artefacto con la referencia de Git refs/tags/{tag} a la compilación completada. Esto proporciona a su equipo una rastreabilidad adicional y una manera más fácil de navegar desde la compilación hasta el código que se creó. La etiqueta se considera un artefacto de compilación, ya que la genera la compilación. Cuando la compilación se elimina manualmente o a través de una directiva de retención, también se elimina la etiqueta .

Estado de compilación del informe (Azure Pipelines, TFS 2017 y versiones posteriores)

Tiene la opción de proporcionar a su equipo una vista del estado de compilación desde el repositorio de origen remoto.

Si los orígenes están en un repositorio de Git de Azure Repos en el proyecto, esta opción muestra un distintivo en la página De códigos para indicar si la compilación se está pasando o no. El estado de compilación se muestra en las pestañas siguientes:

  • Archivos:indica el estado de la compilación más reciente de la rama seleccionada.
  • Confirmaciones:indica el estado de compilación de cada confirmación (esto requiere que el desencadenador de integración continua (CI) esté habilitado para las compilaciones).
  • Ramas:indica el estado de la compilación más reciente de cada rama.

Si usa varias canalizaciones de compilación para el mismo repositorio en el proyecto, puede optar por habilitar esta opción para una o varias de las canalizaciones. En el caso de que esta opción esté habilitada en varias canalizaciones, el distintivo de la página De códigos indica el estado de la compilación más reciente en todas las canalizaciones. Los miembros del equipo pueden hacer clic en el distintivo de estado de compilación para ver el estado de compilación más reciente de cada una de las canalizaciones de compilación.

GitHub

Si los orígenes están en GitHub, esta opción publica el estado de la compilación en GitHub mediante GitHub o las API de estado. Si la compilación se desencadena desde una GitHub de extracción, puede ver el estado en la página GitHub solicitudes de extracción. Esto también le permite establecer directivas de estado dentro GitHub y automatizar las mezclas. Si la compilación se desencadena mediante la integración continua (CI), puede ver el estado de compilación en la confirmación o rama en GitHub.

Otros tipos de repositorios remotos de Git

Si el origen está en cualquier otro tipo de repositorio remoto, no puede usar Azure Pipelines o TFS para publicar automáticamente el estado de compilación en ese repositorio. Sin embargo, puede usar un distintivo de compilación como una manera de integrar y mostrar el estado de compilación dentro de las experiencias de control de versiones.

Ruta de finalización de la compra

Si está desproteyéciendo un único repositorio, de forma predeterminada, el código fuente se desproteerá en un directorio denominado s . Para las canalizaciones YAML, puede cambiarlo especificando checkout con path . La ruta de acceso especificada es relativa a $(Agent.BuildDirectory) . Por ejemplo: si el valor de la ruta de acceso de finalización de la compra es y es , el código mycustompath$(Agent.BuildDirectory) fuente se C:\agent\_work\1 extraerá en C:\agent\_work\1\mycustompath .

Si usa varios pasos y des check-out de varios repositorios, y no especifica explícitamente la carpeta mediante , cada repositorio se coloca en una subcarpeta de denominada después checkoutpath del s repositorio. Por ejemplo, si desprotee dos repositorios denominados y , el código fuente tools se desproteerá code en y C:\agent\_work\1\s\toolsC:\agent\_work\1\s\code .

Tenga en cuenta que el valor de la ruta de acceso de finalización de la compra no se puede establecer para subir los niveles de directorio por encima de , por lo que dará como resultado una ruta de acceso de finalización de la compra válida (es decir, ), pero un valor como no lo hará $(Agent.BuildDirectory)path\..\anotherpathC:\agent\_work\1\anotherpath..\invalidpath (es decir, C:\agent\_work\invalidpath ).

Nota:

La ruta de acceso de desprotección solo se puede especificar para canalizaciones YAML. Para obtener más información, vea Checkout in the YAML schema.

Submódulos de desprotección

Seleccione si desea descargar archivos de submódulos. Puede optar por obtener los submódulos inmediatos o todos los submódulos anidados en cualquier profundidad de recursión. Si desea usar LFS con submódulos, asegúrese de ver la nota sobre el uso de LFS con submódulos.

Nota:

Para obtener más información sobre la sintaxis de YAML para extraer submódulos, vea Checkout in the YAML schema.

La canalización de compilación comprobará los submódulos de Git siempre que sean:

  • No autenticado: Un repositorio público no autenticado sin credenciales necesarias para clonar o capturar.

  • Autenticado:

    • Contenido en el mismo proyecto, organización GitHub o cuenta de Bitbucket Cloud que el repositorio de Git especificado anteriormente.

    • Se agrega mediante una dirección URL relativa al repositorio principal. Por ejemplo, esta se desproteiría: git submodule add /../../submodule.git mymodule Esta no se desproteiría: git submodule add https://dev.azure.com/fabrikamfiber/_git/ConsoleApp mymodule

Nota:

Si ejecuta TFS 2017.1, TFS 2017 RTM o TFS 2015, los submódulos deben ser secundarios (submódulos inmediatos)** del repositorio de Git que ha seleccionado para esta canalización de compilación. En efecto, la canalización de compilación se git submodule update --init ejecuta (no git submodule update -init --recursive ).

Submódulos autenticados

Nota:

Asegúrese de que ha registrado los submódulos mediante HTTPS y no mediante SSH.

Las mismas credenciales que usa el agente para obtener los orígenes del repositorio principal también se usan para obtener los orígenes de los submódulos.

Si el repositorio principal y los submódulos están en un repositorio git de Azure Repos en el proyecto de Azure DevOps, puede seleccionar la cuenta que se usa para acceder a los orígenes. En la pestaña Opciones, en el menú Ámbito de autorización del trabajo de compilación, seleccione una de las siguientes opciones:

  • Project colección para usar la cuenta de servicio Project compilación de colección

  • Proyecto actual para usar la cuenta Project servicio de compilación.

Asegúrese de que la cuenta que use tenga acceso tanto al repositorio principal como a los submódulos.

Si el repositorio principal y los submódulos están en la misma organización GitHub, el token almacenado en la conexión de servicio GitHub se usa para acceder a los orígenes.

Alternativa al uso de la opción Checkout submodules

En algunos casos no se puede usar la opción Desprotección de submódulos. Es posible que tenga un escenario en el que se necesite un conjunto diferente de credenciales para acceder a los submódulos. Esto puede ocurrir, por ejemplo, si el repositorio principal y los repositorios de submódulos no se almacenan en la misma Azure DevOps organización o servicio git.

Si no puede usar la opción Checkout submodules (Extraer submódulos), puede usar un paso de script personalizado para capturar submódulos. En primer lugar, obtenga un token de acceso personal (PAT) y prefiéndolo con pat: . A continuación, codifica en base64 esta cadena con prefijo para crear un token de autenticación básico. Por último, agregue este script a la canalización:

git -c http.https://<url of submodule repository>.extraheader="AUTHORIZATION: basic <BASE64_ENCODED_TOKEN_DESCRIBED_ABOVE>" submodule update --init --recursive

Asegúrese de reemplazar " < BASIC_AUTH_TOKEN " por el token codificado en > Base64.

Use una variable secreta en el proyecto o la canalización de compilación para almacenar el token de autenticación básico que generó. Use esa variable para rellenar el secreto en el comando de Git anterior.

Nota:

P: ¿Por qué no puedo usar un administrador de credenciales de Git en el agente?A: El almacenamiento de las credenciales de submódulo en un administrador de credenciales de Git instalado en el agente de compilación privado no suele ser efectivo, ya que el administrador de credenciales puede solicitar que vuelva a escribir las credenciales cada vez que se actualice el submódulo. Esto no es deseable durante las compilaciones automatizadas cuando no es posible la interacción del usuario.

Desprotección de archivos de LFS

Seleccione si desea descargar archivos de almacenamiento de archivos grandes (LFS).

En el editor clásico, active la casilla para habilitar esta opción.

En una compilación de YAML, agregue un paso de desprotección lfs con establecido en true :

steps:
- checkout: self
  lfs: true
  • TFS 2017 RTM y TFS 2015 (solo macOS y Linux): En la pestaña Variables, establezca en .

Si usa TFS o si usa Azure Pipelines con un agente auto-hospedado, debe instalar en el agente para que esta opción git-lfs funcione. Si los agentes hospedados usan Windows, considere la posibilidad de usar la variable para asegurarse de que las canalizaciones usan las versiones de git y git-lfs que instaló System.PreferGitFromPath en la máquina.

Uso de Git LFS con submódulos

Si un submódulo contiene archivos LFS, se debe configurar Git LFS antes de desprotegía los submódulos. Los agentes de macOS y Linux hospedados por Microsoft vienen preconfigurados de esta manera. Windows agentes y agentes macOS/Linux auto-hospedados no.

Como solución alternativa, si usa YAML, puede agregar el siguiente paso antes de checkout :

steps:
- script: |
    git config --global --add filter.lfs.required true
    git config --global --add filter.lfs.smudge "git-lfs smudge -- %f"
    git config --global --add filter.lfs.process "git-lfs filter-process"
    git config --global --add filter.lfs.clean "git-lfs clean -- %f"
  displayName: Configure LFS for use with submodules
- checkout: self
  lfs: true
  submodules: true
# ... rest of steps ...

Clonación de un segundo repositorio

De forma predeterminada, la canalización está asociada a un repositorio de Azure Repos o un proveedor externo. Este es el repositorio que puede desencadenar compilaciones en confirmaciones y solicitudes de extracción.

Es posible que quiera incluir orígenes de un segundo repositorio en la canalización. Para ello, escriba un script.

git clone https://github.com/Microsoft/TypeScript.git

Si el repositorio no es público, deberá pasar la autenticación al comando de Git.

Azure Repos

La canalización ya tendrá acceso a otros repositorios de su proyecto y puede clonarlos en la canalización mediante un comando de script, como se muestra en el ejemplo siguiente.

- script: | 
    git clone -c http.extraheader="AUTHORIZATION: bearer $(System.AccessToken)" https://organization@dev.azure.com/project/FabrikamFiber/_git/reponame

Puede clonar varios repositorios en el mismo proyecto que la canalización mediante la desprotección de varios repositorios.

Si necesita clonar un repositorio de otro proyecto que no es público, deberá autenticarse como un usuario que tenga acceso a ese proyecto.

Nota:

Use una variable secreta para almacenar las credenciales de forma segura.

Las variables secretas no están disponibles automáticamente para los scripts como variables de entorno. Consulte Variables secretas sobre cómo asignarlas.

Por Azure Repos, puede usar un token de acceso personal con el permiso Código (lectura). Envíe esto como campo de contraseña en un encabezado de autorización "Básico" sin un nombre de usuario. (En otras palabras, codifica en base64 el valor de :<PAT> , incluidos los dos puntos).

AUTH=$(echo -n ":$REPO_PAT" | openssl base64 | tr -d '\n')
git -c http.<repo URL>.extraheader="AUTHORIZATION: basic $AUTH" clone <repo URL> --no-checkout --branch master

No sincronizar orígenes (solo TFS 2017 y versiones más recientes)

Los trabajos que no son de implementación capturan automáticamente orígenes. Use esta opción si desea omitir ese comportamiento. Esta opción puede ser útil en casos en los que desee:

  • Git init, config y fetch mediante sus propias opciones personalizadas.

  • Use una canalización de compilación para ejecutar la automatización (por ejemplo, algunos scripts) que no dependen del código en el control de versiones.

Si desea deshabilitar la descarga de orígenes:

  • Azure Pipelines, TFS 2017.2 y versiones más recientes: Haga clic en Configuraciónavanzada y, a continuación, seleccione No sincronizar orígenes.

  • TFS 2017 RTM: Defina en variables y establezca su valor en false.

Nota:

Cuando se usa esta opción, el agente también omite la ejecución de comandos de Git que limpian el repositorio.

Captura superficial

Seleccione si desea limitar la distancia de la descarga en el historial. De hecho, esto da como resultado git fetch --depth=n . Si el repositorio es grande, esta opción puede hacer que la canalización de compilación sea más eficaz. El repositorio podría ser grande si ha estado en uso durante mucho tiempo y tiene un historial de tamaño. También podría ser grande si agregó y eliminó archivos grandes más adelante.

En estos casos, esta opción puede ayudarle a conservar los recursos de red y almacenamiento. También puede ahorrar tiempo. La razón por la que no siempre ahorra tiempo es porque, en algunas situaciones, es posible que el servidor tenga que dedicar tiempo a calcular las confirmaciones que se descargarán para la profundidad que especifique.

Nota:

Cuando la compilación se pone en cola, la rama que se va a compilar se resuelve en un identificador de confirmación. A continuación, el agente captura la rama y comprueba la confirmación deseada. Hay una pequeña ventana entre el momento en que una rama se resuelve en un identificador de confirmación y el momento en que el agente realiza la desprotección. Si la rama se actualiza rápidamente y establece un valor muy pequeño para la captura superficial, es posible que la confirmación no exista cuando el agente intente comprobarla. Si esto sucede, aumente la configuración de profundidad de captura superficial.

Azure Pipelines, TFS 2018, TFS 2017.2

Después de activar la casilla para habilitar esta opción, en el cuadro Profundidad , especifique el número de confirmaciones.

Sugerencia

La Agent.Source.Git.ShallowFetchDepth variable mencionada a continuación también funciona e invalida los controles de casilla. De este modo, puede modificar la configuración al poner en cola la compilación.

TFS 2017 RTM, TFS 2015 (solo macOS y Linux)

En la pestaña Variables, defina y establezca su valor en el número de confirmaciones del historial que desea descargar. Especifique 0 para no establecer ningún límite.

Preferir Git desde la ruta de acceso

El Windows incluye su propia copia de Git. Si prefiere proporcionar su propio Git en lugar de usar la copia incluida, establezca System.PreferGitFromPath en true . Esta configuración siempre es verdadera en los agentes que no Windows datos.

Opciones de desencadenador para otros git

Cuando se usa un repositorio de Git externo o otro, las compilaciones de CI requieren que se pueda acceder al repositorio desde Internet. Si el repositorio está detrás de un firewall o proxy, solo funcionarán las compilaciones programadas y manuales.

Preguntas más frecuentes

¿Qué protocolos puede usar el agente de compilación con Git?

El agente admite HTTPS.

El agente aún no admite SSH. Consulte Allow build to use SSH authentication while checking out Git submodules (Permitir que la compilación use la autenticación SSH mientras se desprotede los submódulos de Git).

Utilizo TFS en el entorno local y no veo algunas de estas características. ¿Por qué no?

Algunas de estas características solo están disponibles en Azure Pipelines y todavía no lo están en el entorno local. Algunas características están disponibles en el entorno local si ha actualizado a la versión más reciente de TFS.