Compilación Azure Repos git o repositorios git de TFS

  • Artículo
  • 36 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.

Azure Pipelines compilar y validar automáticamente cada solicitud de extracción y confirmar en el repositorio Azure Repos Git.

Elección de un repositorio para compilar

Para crear una canalización, seleccione primero un repositorio y, a continuación, un archivo YAML en ese repositorio. El repositorio en el que está presente el archivo YAML se denomina self repositorio. De forma predeterminada, este es el repositorio que compila la canalización.

Más adelante puede configurar la canalización para que des check out a different repository or multiple repositories(Varios repositorios). Para obtener información sobre cómo hacer esto, vea Desprotección de varios repositorios.

Las canalizaciones yaml no están disponibles en TFS.

Azure Pipelines tener acceso a los repositorios para desencadenar sus compilaciones y capturar su código durante las compilaciones. Normalmente, una canalización tiene acceso a los repositorios del mismo proyecto. Sin embargo, si desea acceder a los repositorios de un proyecto diferente, debe actualizar los permisos concedidos a los tokens de acceso de trabajo.

Desencadenadores de CI

Los desencadenadores de integración continua (CI) hacen que una canalización se ejecute siempre que se inserta una actualización en las ramas especificadas o se insertan las etiquetas especificadas.

Las canalizaciones de YAML se configuran de forma predeterminada con un desencadenador de CI en todas las ramas.

Ramas

Puede controlar qué ramas obtienen desencadenadores de CI con una sintaxis sencilla:

trigger:
- master
- releases/*

Puede especificar el nombre completo de la rama (por ejemplo, master ) o un carácter comodín (por ejemplo, releases/* ). Consulte Caracteres comodín para obtener información sobre la sintaxis de caracteres comodín.

Nota:

No puede usar variables en desencadenadores, ya que las variables se evalúan en tiempo de ejecución (después de que se haya activado el desencadenador).

Nota:

Si usa plantillas para crear archivos YAML, solo puede especificar desencadenadores en el archivo YAML principal para la canalización. No se pueden especificar desencadenadores en los archivos de plantilla.

Para los desencadenadores más complejos que usan exclude o , debe usar la batch sintaxis completa como se muestra en el ejemplo siguiente.

# specific branch build
trigger:
  branches:
    include:
    - master
    - releases/*
    exclude:
    - releases/old*

En el ejemplo anterior, la canalización se desencadenará si se inserta un cambio en la rama maestra o en cualquier rama de versiones. Sin embargo, no se desencadenará si se realiza un cambio en una rama de versiones que comienza por old .

Si especifica una cláusula sin una cláusula , es equivalente a exclude especificar en la cláusula include*include .

Además de especificar nombres de rama en las listas, también puede configurar desencadenadores basados en branches etiquetas con el formato siguiente:

trigger:
  branches:
    include:
      - refs/tags/{tagname}
    exclude:
      - refs/tags/{othertagname}

Si no especifica ningún desencadenador, el valor predeterminado es como si escribiera:

trigger:
  branches:
    include:
    - '*'  # must quote since "*" is a YAML reserved character; we want a string

Importante

Cuando se especifica un desencadenador, reemplaza el desencadenador implícito predeterminado y solo las inserciones en las ramas que están configuradas explícitamente para incluirse desencadenarán una canalización. Las incluyeciones se procesan primero y, a continuación, se quitan las excluyeciones de esa lista.

Ejecuciones de CI de procesamiento por lotes

Si tiene muchos miembros del equipo que cargan cambios con frecuencia, puede que desee reducir el número de ejecuciones que inicia. Si establece en , cuando se ejecuta una canalización, el sistema espera hasta que se complete la ejecución y, a continuación, inicia otra ejecución con todos los cambios que aún no batchtrue se han creado.

# specific branch build with batching
trigger:
  batch: true
  branches:
    include:
    - master

Para aclarar este ejemplo, supongamos que una inserción en la base de datos A maestra hizo que se ejecutara la canalización anterior. Mientras se ejecuta esa canalización, se insertan inserciones B adicionales C y se producen en el repositorio. Estas actualizaciones no inician nuevas ejecuciones independientes inmediatamente. Pero una vez completada la primera ejecución, todas las inserciones hasta ese momento se procesarán por lotes juntos y se inicia una nueva ejecución.

Nota:

Si la canalización tiene varios trabajos y fases, la primera ejecución debe alcanzar un estado terminal completando o omitiendo todos sus trabajos y fases antes de que se pueda iniciar la segunda ejecución. Por este motivo, debe tener cuidado al usar esta característica en una canalización con varias fases o aprobaciones. Si desea procesar por lotes las compilaciones en estos casos, se recomienda dividir el proceso de CI/CD en dos canalizaciones: una para la compilación (con procesamiento por lotes) y otra para las implementaciones.

Rutas de acceso

Puede especificar rutas de acceso de archivo para incluir o excluir.

# specific path build
trigger:
  branches:
    include:
    - master
    - releases/*
  paths:
    include:
    - docs
    exclude:
    - docs/README.md

Al especificar rutas de acceso, debe especificar explícitamente las ramas en las que desencadenar. No se puede desencadenar una canalización solo con un filtro de ruta de acceso; también debe tener un filtro de rama y los archivos modificados que coincidan con el filtro de ruta de acceso deben ser de una rama que coincida con el filtro de rama.

Sugerencias:

  • Las rutas de acceso siempre se especifican con respecto a la raíz del repositorio.
  • Si no establece filtros de ruta de acceso, la carpeta raíz del repositorio se incluye implícitamente de forma predeterminada.
  • Si excluye una ruta de acceso, no puede incluirla a menos que la califique a una carpeta más profunda. Por ejemplo, si excluye /tools, podría incluir /tools/trigger-runs-on-these.
  • El orden de los filtros de ruta de acceso no importa.
  • Las rutas de acceso de Git distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que las carpetas reales.
  • No puede usar variables en las rutas de acceso, ya que las variables se evalúan en tiempo de ejecución (después de que se haya activado el desencadenador).

Etiquetas

Además de especificar etiquetas en las listas como se ha incluido en la sección anterior, puede especificar directamente etiquetas para branches incluir o excluir:

# specific tag
trigger:
  tags:
    include:
    - v2.*
    exclude:
    - v2.0

Si no especifica ningún desencadenador de etiqueta, las etiquetas no desencadenarán canalizaciones de forma predeterminada.

Importante

Si especifica etiquetas en combinación con filtros de rama, el desencadenador se activará si se cumple el filtro de rama o si se cumple el filtro de etiquetas. Por ejemplo, si una etiqueta inserda satisface el filtro de rama, la canalización se desencadena incluso si el filtro de etiquetas excluye la etiqueta, porque la inserción satisface el filtro de rama.

No participar en CI

Deshabilitación del desencadenador de CI

Puede rechazar completamente los desencadenadores de CI si especifica trigger: none .

# A pipeline with no CI trigger
trigger: none

Importante

Al insertar un cambio en una rama, el archivo YAML de esa rama se evalúa para determinar si se debe iniciar una ejecución de CI.

Para obtener más información, vea Desencadenadores en el esquema YAML.

Las canalizaciones yaml no están disponibles en TFS.

Omisión de CI para confirmaciones individuales

También puede decir a Azure Pipelines omitir la ejecución de una canalización que normalmente se desencadenaría una confirmación. Solo tiene que incluir en el mensaje de confirmación de la confirmación ***NO_CI*** HEAD Azure Pipelines omitirá la ejecución de CI.

También puede decir a Azure Pipelines omitir la ejecución de una canalización que normalmente se desencadenaría una confirmación. Solo tiene que incluir en el mensaje de confirmación o la descripción de la confirmación [skip ci] HEAD Azure Pipelines omitirá la ejecución de CI. También puede usar cualquiera de las variaciones siguientes.

  • [skip ci] o [ci skip]
  • skip-checks: true o skip-checks:true
  • [skip azurepipelines] o [azurepipelines skip]
  • [skip azpipelines] o [azpipelines skip]
  • [skip azp] o [azp skip]
  • ***NO_CI***

Uso del tipo de desencadenador en condiciones

Es un escenario común ejecutar diferentes pasos, trabajos o fases en la canalización en función del tipo de desencadenador que inició la ejecución. Puede hacerlo mediante la variable del sistema Build.Reason . Por ejemplo, agregue la siguiente condición al paso, trabajo o fase para excluirla de las validaciones de solicitudes de solicitud de acceso.

condition: and(succeeded(), ne(variables['Build.Reason'], 'PullRequest'))

Comportamiento de los desencadenadores cuando se crean nuevas ramas

Es habitual configurar varias canalizaciones para el mismo repositorio. Por ejemplo, puede tener una canalización para compilar los documentos de la aplicación y otra para compilar el código fuente. Puede configurar desencadenadores de CI con filtros de rama y filtros de ruta de acceso adecuados en cada una de estas canalizaciones. Por ejemplo, puede que desee que una canalización se desencadene al insertar una actualización en la carpeta y otra que se desencadene al insertar una actualización en el docs código de la aplicación. En estos casos, debe comprender cómo se desencadenan las canalizaciones cuando se crea una nueva rama.

Este es el comportamiento al insertar una nueva rama (que coincide con los filtros de rama) en el repositorio:

  • Si la canalización tiene filtros de ruta de acceso, solo se desencadenará si la nueva rama tiene cambios en los archivos que coinciden con ese filtro de ruta de acceso.
  • Si la canalización no tiene filtros de ruta de acceso, se desencadenará incluso si no hay cambios en la nueva rama.

Caracteres comodín

Al especificar una rama o etiqueta, puede usar un nombre exacto o un carácter comodín. Los patrones de caracteres comodín permiten que coincidan con cero o * más caracteres y que ? coincidan con un solo carácter.

  • Si inicia el patrón con * en una canalización de YAML, debe encapsular el patrón entre comillas, como "*-releases" .
  • En el caso de las ramas, etiquetas y rutas de acceso, puede aparecer un carácter comodín en cualquier parte del patrón.
trigger:
  branches:
    include:
    - master
    - releases/*
    - feature/*
    exclude:
    - releases/old*
    - feature/*-working
  paths:
    include:
    - docs/*.md

Desencadenadores de PR

Los desencadenadores de solicitud de extracción (PR) hacen que una canalización se ejecute siempre que se abra una solicitud de extracción con una de las ramas de destino especificadas o cuando se insertan cambios en dicha solicitud de extracción. En Azure Repos Git, esta funcionalidad se implementa mediante directivas de rama. Para habilitar la validación de solicitudes de extracción en Azure Git Repos, vaya a las directivas de rama de la rama deseada y configure la directiva de validación de compilación para esa rama. Para obtener más información, vea Configurar directivas de rama.

Nota:

Para configurar compilaciones de validación para Azure Repos repositorio git, debe ser administrador de proyectos de su proyecto.

Nota:

Las solicitudes de extracción de borrador no desencadenan una canalización aunque configure una directiva de rama.

Validación de contribuciones desde bifurcaciones

La creación de solicitudes de Azure Repos bifurcaciones no es diferente de la creación de solicitudes de extracción en el mismo repositorio o proyecto. Solo puede crear bifurcaciones dentro de la misma organización de la que forma parte el proyecto.

Limitación del ámbito de autorización de trabajos

Azure Pipelines proporciona varias opciones de seguridad para configurar el ámbito de autorización de trabajo con el que se ejecutan las canalizaciones.

Limitar el ámbito de autorización del trabajo al proyecto actual

Azure Pipelines proporciona dos límites de ámbito de autorización de trabajos a la configuración actual del proyecto:

  • Limitar el ámbito de autorización del trabajo al proyecto actual para las canalizaciones que no son de versión: esta configuración se aplica a las canalizaciones yaml y a las canalizaciones de compilación clásicas. Esta configuración no se aplica a las canalizaciones de versión clásicas.
  • Limitar el ámbito de autorización del trabajo al proyecto actual para las canalizaciones de versión: esta configuración solo se aplica a las canalizaciones de versión clásicas.

Pipelines ejecutar con tokens de acceso con ámbito de recopilación a menos que esté habilitada la configuración pertinente para el tipo de canalización. La configuración Limitar ámbito de autorización de trabajo permite reducir el ámbito de acceso de todas las canalizaciones al proyecto actual. Esto puede afectar a la canalización si accede a un Azure Repos git en un proyecto diferente de su organización.

Si el repositorio de Git de Azure Repos está en un proyecto diferente al de la canalización y la opción Limitar ámbito de autorización de trabajo para el tipo de canalización está habilitada, debe conceder permiso a la identidad del servicio de compilación para la canalización en el segundo proyecto. Para más información, consulte Administración de permisos de cuenta de servicio de compilación.

Azure Pipelines proporciona una configuración de seguridad para configurar el ámbito de autorización de trabajo con el que se ejecutan las canalizaciones.

  • Limitar el ámbito de autorización del trabajo al proyecto actual: esta configuración se aplica a las canalizaciones yaml y a las canalizaciones de compilación clásicas. Esta configuración no se aplica a las canalizaciones de versión clásicas.

Pipelines ejecutar con tokens de acceso con ámbito de recopilación a menos que esté habilitado limitar el ámbito de autorización del trabajo al proyecto actual. Esta configuración permite reducir el ámbito de acceso de todas las canalizaciones al proyecto actual. Esto puede afectar a la canalización si accede a un Azure Repos git en un proyecto diferente de su organización.

Si el repositorio de Git de Azure Repos está en un proyecto diferente al de la canalización y la opción Limitar ámbito de autorización de trabajo está habilitada, debe conceder permiso a la identidad del servicio de compilación para la canalización en el segundo proyecto. Para obtener más información, vea Ámbito de autorización de trabajos.

Para obtener más información sobre limitar el ámbito de autorización de trabajos,consulte Información sobre los tokens de acceso a trabajos.

Limitar el ámbito de autorización de trabajos a los repositorios de Azure DevOps referencia

Pipelines puede acceder a los repositorios de Azure DevOps en proyectos autorizados, tal y como se describe en la sección Anterior Limitar el ámbito de autorización de trabajos al proyecto actual, a menos que se habilite Limitar el ámbito de autorización de trabajo a los repositorios de Azure DevOps a los que se hace referencia. Con esta opción habilitada, puede reducir el ámbito de acceso de todas las canalizaciones Azure DevOps repositorios a los que hace referencia explícitamente un paso o una instrucción en el trabajo de canalización que usa ese checkoutuses repositorio.

Para configurar esta opción, vaya a Pipelines, Configuración en Configuración de la organización o Project configuración . Si está habilitada en el nivel de organización, la configuración aparece atenuada y no está disponible en el nivel de configuración del proyecto.

Importante

Limitar el ámbito de autorización de trabajo a los repositorios de Azure DevOps a los que se hace referencia está habilitado de forma predeterminada para las nuevas organizaciones y proyectos creados después de mayo de 2020.

Cuando se habilita Limitar el ámbito de autorización de trabajo Azure DevOps los repositorios de Azure DevOps a los que se hace referencia, las canalizaciones YAML deben hacer referencia explícitamente a los repositorios de Git de Azure Repos que quiera usar en la canalización como paso de desprotección en el trabajo que usa el repositorio. No podrá capturar código mediante tareas de scripting y comandos git para un repositorio de Git de Azure Repos a menos que primero se haga referencia explícitamente a ese repositorio.

Hay algunas excepciones en las que no es necesario hacer referencia explícitamente a un repositorio git de Azure Repos antes de usarlo en la canalización cuando se habilita Limitar el ámbito de autorización de trabajo a los repositorios de Azure DevOps a los que se hace referencia.

  • Si no tiene un paso de desprotección explícito en la canalización, es como si tiene un paso y el repositorio checkout: selfself se desproteme.
  • Si usa un script para realizar operaciones de solo lectura en un repositorio de un proyecto público, no es necesario hacer referencia al repositorio de proyectos públicos en un checkout paso.
  • Si usa un script que proporciona su propia autenticación en el repositorio, como un PAT, no es necesario hacer referencia a ese repositorio en un checkout paso.

Por ejemplo, cuando se habilita Limitar el ámbito de autorización de trabajo a los repositorios de Azure DevOps a los que se hace referencia, si la canalización está en el repositorio de la organización y desea usar un script para des consultar el repositorio, debe hacer referencia a este repositorio en un paso o con una instrucción FabrikamProject/FabrikamToolscheckoutuses .

Si ya está desproteyéciendo el repositorio en la canalización mediante un paso de desprotección, posteriormente puede usar scripts para interactuar FabrikamTools con ese repositorio.

steps:
- checkout: git://FabrikamFiber/FabrikamTools # Azure Repos Git repository in the same organization
- script: # Do something with that repo

# Or you can reference it with a uses statement in the job
uses:
  repositories: # List of referenced repositories
  - FabrikamTools # Repository reference to FabrikamTools

steps:
- script: # Do something with that repo like clone it

Nota:

En muchos escenarios, se puede aprovechar la desprotección de varios repositorios, lo que elimina la necesidad de usar scripts para consultar repositorios adicionales en la canalización. Para obtener más información, consulte Des check out multiple repositories in your pipeline (Des consultar varios repositorios en la canalización).

Restauración

Cuando se desencadena una canalización, Azure Pipelines el código fuente del repositorio Azure Repos Git. Puede controlar varios aspectos de cómo sucede esto.

Nota:

Al incluir un paso de desprotección en la canalización, ejecutamos el siguiente comando: git -c fetch --force --tags --prune --prune-tags --progress --no-recurse-submodules origin . Si esto no satisface sus necesidades, puede optar por excluir la desprotección integrada y, a continuación, usar una tarea checkout: none de script para realizar su propia desprotección.

Versión preferida de Git

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.

Ruta de acceso de finalización de la compra

Si está desproteyéndo un único repositorio, de forma predeterminada, el código fuente se desproteerá en un directorio denominado s . Para las canalizaciones YAML, puede cambiar esto especificando checkout con path un . 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 está usando 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 con el nombre del checkoutpaths repositorio. Por ejemplo, si desprotee dos repositorios denominados y , el código tools fuente 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 ningún nivel 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 ).

Puede configurar el valor path en el paso path de la canalización.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Submódulos

Puede configurar el valor submodules en el paso submodules de la canalización si desea descargar archivos de los submódulos.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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 que el repositorio Azure Repos Git especificado anteriormente. 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.

    • Se agrega mediante una dirección URL relativa al repositorio principal. Por ejemplo

      • Este se desproteiría: git submodule add ../../../FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

        En este ejemplo, el submódulo hace referencia a un repositorio (FabrikamFiber) de la misma organización Azure DevOps, pero en un proyecto diferente (FabrikamFiberProject). 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. Esto requiere que el token de acceso del trabajo tenga acceso al repositorio en el segundo proyecto. Si ha restringido el token de acceso al trabajo como se explicó en la sección anterior, no podrá hacerlo. Puede permitir que el token de acceso del trabajo acceda al repositorio en el segundo proyecto si (a) concede explícitamente acceso a la cuenta de servicio de compilación del proyecto en el segundo proyecto o (b) mediante tokens de acceso con ámbito de colección en lugar de tokens de ámbito de proyecto para toda la organización. Para obtener más información sobre estas opciones y sus implicaciones de seguridad, consulte Acceso a repositorios, artefactos y otros recursos.

      • Este no se desproteiría: git submodule add https://fabrikam-fiber@dev.azure.com/fabrikam-fiber/FabrikamFiberProject/_git/FabrikamFiber FabrikamFiber

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 están almacenados en la misma organización de Azure DevOps o si el token de acceso del trabajo no tiene acceso al repositorio en un proyecto diferente.

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_STRING>" submodule update --init --recursive

Asegúrese de reemplazar " < BASE64_ENCODED_STRING " por la cadena "pat:token" codificada 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.

Captura superficial

Es posible que quiera 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.

Puede configurar el valor fetchDepth en el paso fetchDepth de la canalización.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

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 se inicia la canalización, 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.

No sincronizar orígenes

Es posible que quiera omitir la captura de nuevas confirmaciones. 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.

Puede configurar la opción No sincronizar orígenes en el paso Desprotección de la canalización; para ello, establezca .

steps:
- checkout: none  # Don't sync sources

Nota:

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

Compilación limpia

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 de forma incremental 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 porque cada vez se obtiene un nuevo agente.

Puede configurar el valor clean en el paso clean de la canalización.

steps:
- checkout: self  # self represents the repo where the initial Pipelines YAML file was found
  clean: boolean  # whether to fetch clean each time
  fetchDepth: number  # the depth of commits to ask Git to fetch
  lfs: boolean  # whether to download Git-LFS files
  submodules: true | recursive  # set to 'true' for a single level of submodules or 'recursive' to get submodules of submodules
  path: string  # path to check out source code, relative to the agent's build directory (e.g. \_work\1)
  persistCredentials: boolean  # set to 'true' to leave the OAuth token in the Git config after the initial fetch

Cuando clean se establece en la canalización de true compilación, realiza una deshacer los cambios en $(Build.SourcesDirectory) . Más concretamente, los siguientes comandos de Git se ejecutan antes de capturar el origen.

git clean -ffdx
git reset --hard HEAD

Para obtener más opciones, puede configurar la workspace configuración de un workspace.

jobs:
- job: string  # name of the job, A-Z, a-z, 0-9, and underscore
  ...
  workspace:
    clean: outputs | resources | all # what to clean up before the job runs

Esto proporciona las siguientes opciones de limpieza.

  • outputs: la misma operación que la configuración limpia descrita en la tarea de desprotección anterior, además de: Elimina y vuelve a crear . Tenga en cuenta que y siempre se eliminan y se vuelven a crear antes de cada compilación, independientemente $(Build.ArtifactStagingDirectory) de cualquiera de estas $(Common.TestResultsDirectory) opciones.

  • resources: elimina y vuelve a crear . Esto da como resultado la inicialización de un nuevo repositorio de Git local para cada compilación.

  • all: elimina y vuelve a crear . Esto da como resultado la inicialización de un nuevo repositorio de Git local para cada compilación.

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

Actualmente no se puede configurar esta opción en YAML, pero sí en el editor clásico. Al editar una canalización de YAML, puede acceder al editor clásico eligiendo cualquiera de los desencadenadores en el menú del editor de YAML.

Configure las opciones de Git, YAML.

En el editor clásico, elija YAML,elija la tarea Obtener orígenes y, a continuación, configure las propiedades deseadas allí.

En el editor clásico, elija OBTENER orígenes de YAML.

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

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

Las cuatro primeras variables están predefinidas. My.Variable puede definirlo en la pestaña 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, la etiqueta no se crea.

Una vez que la canalización de compilación etiqueta los orígenes, se agrega automáticamente un artefacto con la referencia de Git a refs/tags/{tag} la compilación completada. Esto proporciona a su equipo 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.

Preguntas más frecuentes

Los problemas relacionados con Azure Repos integración se divide en tres categorías:

Desencadenadores con errores

Acabo de crear una nueva canalización yaml con desencadenadores de CI/PR, pero la canalización no se está desencadenando.

Siga cada uno de estos pasos para solucionar los errores de los desencadenadores:

  • ¿Los desencadenadores de CI o PR de YAML se reemplazan por la configuración de canalización en la interfaz de usuario? Al editar la canalización, elija ... y, a continuación, Desencadenadores.

    Interfaz de usuario de configuración de canalización.

    Compruebe la opción Invalidar el desencadenador YAML desde aquí para ver los tipos de desencadenador (integración continua o validación de solicitudes de incorporación de incorporación de recursos) disponibles para el repositorio.

    Invalide el desencadenador YAML desde aquí.

  • ¿Está configurando el desencadenador de pr en el archivo YAML o en las directivas de rama para el repositorio? Para un Azure Repos de Git, no se puede configurar un desencadenador de pr en el archivo YAML. Debe usar directivas de rama.

  • ¿La canalización está en pausa o deshabilitada? Abra el editor de la canalización y, a continuación, seleccione Configuración para comprobar. Si la canalización está en pausa o deshabilitada, los desencadenadores no funcionan.

  • ¿Ha actualizado el archivo YAML en la rama correcta? Si inserta una actualización en una rama, el archivo YAML de esa misma rama rige el comportamiento de ci. Si inserta una actualización en una rama de origen, el archivo YAML resultante de combinar la rama de origen con la rama de destino rige el comportamiento de la pr. Asegúrese de que el archivo YAML de la rama correcta tiene la configuración de CI o PR necesaria.

  • ¿Ha configurado el desencadenador correctamente? Al definir un desencadenador YAML, puede especificar cláusulas include y exclude para ramas, etiquetas y rutas de acceso. Asegúrese de que la cláusula include coincide con los detalles de la confirmación y de que la cláusula exclude no los excluye. Compruebe la sintaxis de los desencadenadores y asegúrese de que es precisa.

  • ¿Ha usado variables para definir el desencadenador o las rutas de acceso? No se admite.

  • ¿Ha usado plantillas para el archivo YAML? Si es así, asegúrese de que los desencadenadores están definidos en el archivo YAML principal. No se admiten los desencadenadores definidos dentro de los archivos de plantilla.

  • ¿Ha excluido las ramas o rutas de acceso en las que ha incluido los cambios? Pruebe mediante la insertar un cambio en una ruta de acceso incluida en una rama incluida. Tenga en cuenta que las rutas de acceso de los desencadenadores distinguen mayúsculas de minúsculas. Asegúrese de usar el mismo caso que el de las carpetas reales al especificar las rutas de acceso en los desencadenadores.

  • ¿Acaba de insertar una rama nueva? Si es así, es posible que la nueva rama no inicie una nueva ejecución. Consulte la sección "Comportamiento de los desencadenadores cuando se crean nuevas ramas".

Mis desencadenadores de CI o PR han funcionado bien. Pero ahora han dejado de funcionar.

En primer lugar, siga los pasos de solución de problemas de la pregunta anterior. A continuación, siga estos pasos adicionales:

  • ¿Tiene conflictos de combinación en la pr. Para una solicitud de solicitud de cambios que no desencadene una canalización, ábrala y compruebe si tiene un conflicto de combinación. Resuelva el conflicto de combinación.

  • ¿Experimenta un retraso en el procesamiento de eventos de inserción o de solicitudes de inserción? Normalmente, puede comprobar esto comprobando si el problema es específico de una sola canalización o es común a todas las canalizaciones o repositorios del proyecto. Si una inserción o una actualización de solicitudes de inserción en cualquiera de los repositorios muestran este síntoma, es posible que experimentemos retrasos en el procesamiento de los eventos de actualización. Compruebe si se está experimentando una interrupción del servicio en nuestra página de estado. Si la página de estado muestra un problema, nuestro equipo debe haber empezado a trabajar en él. Compruebe la página con frecuencia para obtener actualizaciones sobre el problema.

No quiero que los usuarios invalide la lista de ramas para desencadenadores cuando actualicen el archivo YAML. ¿Cómo puedo hacerlo?

Los usuarios con permisos para contribuir con código pueden actualizar el archivo YAML e incluir o excluir ramas adicionales. Como resultado, los usuarios pueden incluir su propia característica o rama de usuario en su archivo YAML e insertar esa actualización en una característica o rama de usuario. Esto puede hacer que se desencadene la canalización para todas las actualizaciones de esa rama. Si desea evitar este comportamiento, puede hacer lo siguiente:

  1. Edite la canalización en la interfaz Azure Pipelines usuario.
  2. Vaya al menú Desencadenadores.
  3. Seleccione Invalidar el desencadenador de integración continua de YAML desde aquí.
  4. Especifique las ramas que se incluirán o excluirán para el desencadenador.

Al seguir estos pasos, se omiten los desencadenadores de CI especificados en el archivo YAML.

Tengo varios repositorios en mi canalización de YAML. Cómo configurar desencadenadores para cada repositorio?

Vea desencadenadores en Uso de varios repositorios.

Error de desprotección

Veo el siguiente error en el archivo de registro durante el paso de finalización de la compra. ¿Cómo puedo corregirlo?

remote: TF401019: The Git repository with name or identifier XYZ does not exist or you do not have permissions for the operation you are attempting.
fatal: repository 'XYZ' not found
##[error] Git fetch failed with exit code: 128

Siga cada uno de estos pasos para solucionar los errores de los desencadenadores:

  • ¿Sigue existiendo el repositorio? En primer lugar, asegúrese de que lo hace, para lo que debe abrirla en Repos página.

  • ¿Está accediendo al repositorio mediante un script? Si es así, compruebe la opción Limitar el ámbito de autorización del trabajo a los repositorios de Azure DevOps referencia. Cuando se habilita Limitar el ámbito de autorización de trabajo a los repositorios de Azure DevOps a los que se hace referencia, no podrá consultar los repositorios de Git de Azure Repos mediante un script a menos que se haga referencia a ellos explícitamente en primer lugar en la canalización.

  • ¿Cuál es el ámbito de autorización de trabajo de la canalización?

    • Si el ámbito es colección:

      • Puede ser un error intermitente. Vuelva a ejecutar la canalización.
      • Es posible que alguien haya quitado el acceso a Project de servicio de compilación de recopilación.
        • Vaya a la configuración del proyecto en el que existe el repositorio. Seleccione Repos > Repositorios: > repositorio específico.
        • Compruebe si Project servicio de compilación de recopilación de recopilación (nombre-colección) existe en la lista de usuarios.
        • Compruebe si esa cuenta tiene la etiqueta Crear y el acceso de lectura.

    • Si el ámbito es project:

      • ¿Está el repositorio en el mismo proyecto que la canalización?
        • Yes:
          • Puede ser un error intermitente. Vuelva a ejecutar la canalización.
          • Es posible que alguien haya quitado el acceso a Project cuenta del servicio de compilación.
            • Vaya a la configuración del proyecto en el que existe el repositorio. Seleccione Repos > Repositorios: > repositorio específico.
            • Compruebe si el servicio de compilación your-project-name (nombre-colección) existe en la lista de usuarios.
            • Compruebe si esa cuenta tiene la etiqueta Crear y el acceso de lectura.
        • No:
          • ¿La canalización está en un proyecto público?
            • Sí: no puede acceder a recursos fuera del proyecto público. Haga que el proyecto sea privado.
            • No: debe realizar pasos adicionales para conceder acceso. Supongamos que la canalización existe en el proyecto A y que el repositorio existe en el proyecto B.
              • Vaya a la configuración del proyecto en el que existe el repositorio (B). Seleccione Repos > Repositorios: > repositorio específico.
              • Agregue your-project-name Build Service (your-collection-name) a la lista de usuarios, donde your-project-name es el nombre del proyecto en el que existe la canalización (A).
              • Dé a Crear etiqueta y Acceso de lectura a la cuenta.

Versión incorrecta

Se usa una versión incorrecta del archivo YAML en la canalización. ¿Por qué ocurre esto?

  • En el caso de los desencadenadores de CI, se evalúa el archivo YAML que se encuentra en la rama que se va a insertar para ver si se debe ejecutar una compilación de CI.
  • En el caso de los desencadenadores de pr, el archivo YAML resultante de combinar las ramas de origen y destino de la pr se evalúa para ver si se debe ejecutar una compilación de pr.