Secuencia de ejecución de canalización

  • Artículo

Azure DevOps Services | Azure DevOps Server 2022 | Azure DevOps Server 2019

Las ejecuciones representan una ejecución de una canalización. Durante una ejecución, la canalización se procesa y los agentes procesan uno o varios trabajos. Una ejecución de canalización incluye trabajos, pasos y tareas. Ejecuta la potencia de las canalizaciones de integración continua (CI) y entrega continua (CD).

Información general de la canalización

Al ejecutar una canalización, se producen muchas cosas en segundo plano. Aunque a menudo no necesitará saberlas, a veces es útil tener una visión general. En un nivel alto, Azure Pipelines hará lo siguiente:

En el lado del agente, para cada trabajo, un agente hará lo siguiente:

Es posible que los trabajos se realicen correctamente, produzcan errores o se cancelen. También hay situaciones en las que es posible que un trabajo no se complete. Comprender cómo sucede esto puede ayudarle a solucionar problemas.

Vamos a desglosar cada acción una por una.

Procesamiento de la canalización

Expansión de plantillas YAML

Para convertir una canalización en una ejecución, Azure Pipelines sigue varios pasos en este orden:

  1. En primer lugar, expanda plantillas y evalúe expresiones de plantilla.
  2. A continuación, evalúe las dependencias en el nivel de fase para elegir las primeras fases que se van a ejecutar.
  3. Para cada fase seleccionada para ejecutarse, suceden dos cosas:
  4. Para cada trabajo seleccionado para ejecutarse, expanda varias configuraciones (strategy: matrix o strategy: parallel en YAML) en varios trabajos en tiempo de ejecución.
  5. Para cada trabajo en tiempo de ejecución, evalúe las condiciones para decidir si ese trabajo es apto para ejecutarse.
  6. Solicite un agente para cada trabajo en tiempo de ejecución apto.

A medida que se completen los trabajos en tiempo de ejecución, Azure Pipelines verá si hay nuevos trabajos aptos para ejecutarse. Si es así, los pasos 4 a 6 se repiten con los nuevos trabajos. De forma similar, a medida que se completan las fases, se repetirán los pasos 2 a 6 para las nuevas fases.

Este orden ayuda a responder a una pregunta común: ¿por qué no puedo usar determinadas variables en mis parámetros de plantilla? El paso 1, la expansión de plantillas, funciona únicamente en el texto del documento YAML. Las variables en tiempo de ejecución no existen durante ese paso. Después del paso 1, los parámetros de plantilla se han resuelto y ya no existen.

También responde a otro problema común: ¿por qué no puedo usar variables para resolver la conexión de servicio o los nombres de entorno? Los recursos están autorizados antes de que una fase pueda empezar a ejecutarse, por lo que las variables de nivel de trabajo y de fase no están disponibles. Se pueden usar variables de nivel de canalización, pero solo las incluidas explícitamente en la canalización. Los grupos de variables son ellos mismos un recurso sujeto a la autorización, por lo que sus datos tampoco están disponibles al comprobar la autorización de recursos.

Solicitud de un agente

Siempre que Azure Pipelines necesite ejecutar un trabajo, pedirá al grupo un agente. (Lostrabajos de servidor son una excepción, ya que se ejecutan en el propio servidor de Azure Pipelines). Los grupos de agentes hospedados por Microsoft y autohospedados funcionan de forma ligeramente diferente.

Solicitudes de grupo de agentes hospedados por Microsoft

En primer lugar, el servicio comprueba los trabajos paralelos de la organización. Agrega todos los trabajos en ejecución en todos los agentes hospedados por Microsoft y lo compara con el número de trabajos paralelos adquiridos. Si no hay ranuras paralelas disponibles, el trabajo tiene que esperar a que una ranura se libere.

Una vez disponible una ranura paralela, el trabajo se enruta al tipo de agente solicitado. Conceptualmente, el grupo hospedado por Microsoft es un grupo global gigante de máquinas. (En realidad, es muchos grupos físicos diferentes divididos por geografía y tipo de sistema operativo). Según vmImage (en YAML) o el nombre del grupo (en el editor clásico) solicitados, se selecciona un agente.

Selección del grupo

Todos los agentes del grupo de Microsoft son máquinas virtuales nuevas que no han ejecutado ninguna canalización antes. Cuando se complete el trabajo, se descartará la máquina virtual del agente.

Solicitudes de grupo de agentes autohospedados

De forma similar al grupo hospedado por Microsoft, el servicio comprueba primero los trabajos paralelos de la organización. Agrega los trabajos en ejecución en todos los agentes autohospedados y compara con el número de trabajos paralelos adquiridos. Si no hay ranuras paralelas disponibles, el trabajo tiene que esperar a que una ranura se libere.

Una vez disponible una ranura paralela, se examina el grupo autohospedado para un agente compatible. Los agentes autohospedados ofrecen funcionalidades, que son cadenas que indican que el software concreto está instalado o se configuran las opciones. La canalización tiene demandas, que son las funcionalidades necesarias para ejecutar el trabajo. Si no se encuentra un agente gratuito cuyas funcionalidades coincidan con las demandas de la canalización, el trabajo continuará esperando. Si no hay ningún agente en el grupo cuyas funcionalidades coincidan con las demandas, se producirá un error en el trabajo.

Normalmente, los agentes autohospedados suelen reutilizarse de una ejecución a otra. En el caso de los agentes autohospedados, un trabajo de canalización puede tener efectos secundarios, como el calentamiento de cachés o tener la mayoría de confirmaciones ya disponibles en el repositorio local.

Preparación para ejecutar un trabajo

Una vez que un agente ha aceptado un trabajo, tiene que hacer algunos preparativos. El agente descarga (y almacena en caché para la próxima vez) todas las tareas necesarias para ejecutar el trabajo. Crea espacio de trabajo en disco para contener el código fuente, los artefactos y las salidas usados en la ejecución. A continuación, comienza a ejecutar pasos.

Ejecución de cada paso

Los pasos se ejecutan secuencialmente, uno después de otro. Antes de que se pueda iniciar un paso, todos los pasos anteriores deben finalizarse (u omitirse).

Ejecución de cada tarea

Las tareas implementan los pasos. Las propias tareas se implementan como scripts de Node.js o PowerShell. El sistema de tareas enruta las entradas y salidas a los scripts de respaldo. También proporciona algunos servicios comunes, como modificar la ruta del sistema y crear nuevas variables de canalización.

Cada paso se ejecuta en su propio proceso, aislándolo del entorno que dejó los pasos anteriores. Debido a este modelo de proceso por paso, las variables de entorno no se conservan entre los pasos. Sin embargo, las tareas y los scripts tienen un mecanismo para comunicarse con el agente: comandos de registro. Cuando una tarea o script escribe un comando de registro en estándar, el agente realizará cualquier acción solicitada.

Hay un comando de agente para crear nuevas variables de canalización. Las variables de canalización se convertirán automáticamente en variables de entorno en el siguiente paso. Para establecer una nueva variable myVar con un valor de myValue, un script puede hacer lo siguiente:

echo '##vso[task.setVariable variable=myVar]myValue'

Write-Host "##vso[task.setVariable variable=myVar]myValue"

Informar y recopilar resultados

Cada paso puede notificar advertencias, errores y fallos. Los errores y advertencias se notifican a la página de resumen de la canalización, lo que marca la tarea como "correcta con problemas". Los fallos también se notifican a la página de resumen, pero marcan la tarea como "fallida". Un paso falla si notifica explícitamente un error (mediante un comando ##vso) o finaliza el script con un código de salida distinto de cero.

Los registros y los resultados fluyen del agente al servicio

A medida que se ejecutan los pasos, el agente envía constantemente líneas de salida al servicio. Por eso puede ver una fuente en directo de la consola. Al final de cada paso, la salida completa también se carga como un archivo de registro. Los registros se pueden descargar una vez finalizada la canalización. Otros elementos que el agente puede cargar incluyen artefactos y resultados de pruebas. También están disponibles una vez completada la canalización.

Estado y condiciones

El agente realiza un seguimiento del éxito o error de cada paso. A medida que los pasos se realizan correctamente con problemas o con fallos, el estado del trabajo se actualizará. El trabajo siempre refleja el "peor" resultado de cada uno de sus pasos: si se produce un fallo en un paso, el trabajo también produce un error.

Antes de ejecutar un paso, el agente comprobará la condición de ese paso para determinar si se debe ejecutar. De forma predeterminada, un paso solo se ejecutará cuando el estado del trabajo se realice correctamente o se realice correctamente con problemas. Muchos trabajos tienen pasos de limpieza que deben ejecutarse independientemente de lo que haya ocurrido, por lo que pueden especificar una condición de "always()". Los pasos de limpieza también se pueden establecer para ejecutarse solo en la cancelación. Un paso de limpieza correcto no puede guardar el trabajo en caso de error; los trabajos nunca pueden volver a ser correctos después de fallar.

Tiempos de espera y desconexiones

Cada trabajo tiene un tiempo de espera. Si el trabajo no se ha completado en la hora especificada, el servidor cancelará el trabajo. Intentará indicar al agente que se detenga y marcará el trabajo como cancelado. En el lado del agente, esto significa cancelar todos los pasos restantes y cargar los resultados restantes.

Los trabajos tienen un período de gracia conocido como tiempo de espera de cancelación en el que completar cualquier trabajo de cancelación. (Recuerde que los pasos se pueden marcar para ejecutarse incluso en la cancelación). Después del tiempo de espera más el tiempo de espera de cancelación, si el agente no ha notificado que el trabajo se ha detenido, el servidor marcará el trabajo como un error.

Dado que Azure Pipelines distribuye el trabajo a las máquinas del agente, de vez en cuando, los agentes pueden dejar de responder al servidor. Esto puede ocurrir si la máquina host del agente desaparece (pérdida de energía, máquina virtual desactivada) o si se produce un error de red. Para ayudar a detectar estas condiciones, el agente envía un mensaje de latido una vez por minuto para que el servidor sepa que sigue funcionando. Si el servidor no recibe un latido durante cinco minutos consecutivos, supone que el agente no volverá. El trabajo se marca como un error, lo que permite al usuario saber que debe reintentar la canalización.

Administración de ejecuciones a través de la CLI

Con la CLI de Azure DevOps, puede enumerar las ejecuciones de canalización en el proyecto y ver detalles sobre una ejecución específica. También puede agregar y eliminar etiquetas en la ejecución de la canalización.

Requisitos previos

  • Debe haber instalado la extensión de la CLI de Azure DevOps como se describe en Introducción a la CLI de Azure DevOps.
  • Iniciar sesión en Azure DevOps mediante az login.
  • Para ver los ejemplos de este artículo, establezca la organización predeterminada mediante az devops configure --defaults organization=YourOrganizationURL.

Enumerar ejecuciones de canalización

Enumere las ejecuciones de canalización en el proyecto con el comando az pipelines runs list. Para empezar, consulte Introducción a la CLI de Azure DevOps.

az pipelines runs list [--branch]
                       [--org]
                       [--pipeline-ids]
                       [--project]
                       [--query-order {FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc, StartTimeDesc}]
                       [--reason {all, batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated, validateShelveset}]
                       [--requested-for]
                       [--result {canceled, failed, none, partiallySucceeded, succeeded}]
                       [--status {all, cancelling, completed, inProgress, none, notStarted, postponed}]
                       [--tags]
                       [--top]

Parámetros opcionales

  • branch: filtre por compilaciones para esta rama.
  • org: la URL de la organización de Azure DevOps. Puede configurar la organización predeterminada mediante az devops configure -d organization=ORG_URL. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config. Ejemplo: --org https://dev.azure.com/MyOrganizationName/.
  • pipeline-ids: identificadores separados por espacios de definiciones para las que se enumeran las compilaciones.
  • project: el nombre o id. del proyecto. El proyecto predeterminado se puede configurar mediante az devops configure -d project=NAME_OR_ID. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config.
  • query-order: defina el orden en el que se muestran las ejecuciones de canalización. Los valores aceptados son FinishTimeAsc, FinishTimeDesc, QueueTimeAsc, QueueTimeDesc, StartTimeAsc y StartTimeDesc.
  • reason: solo se muestran compilaciones de lista por este motivo especificado. Los valores aceptados son batchedCI, buildCompletion, checkInShelveset, individualCI, manual, pullRequest, schedule, triggered, userCreated y validateShelveset.
  • requested-for: limite a las compilaciones solicitadas para un usuario o grupo especificados.
  • result: limite a las compilaciones con un resultado especificado. Los valores aceptados son cancelado, fallido, ninguno, parcialmente correcto y correcto.
  • status: limite a las compilaciones con un estado especificado. Los valores aceptados son todos, cancelando, completado, en progreso, ninguno, sin empezary pospuestos.
  • tags: limite a las compilaciones con cada una de las etiquetas especificadas. Separados por espacios.
  • top: número máximo de compilaciones que se van a enumerar.

Ejemplo

El siguiente comando enumera las tres primeras ejecuciones de canalización que tienen un estado completado y un resultado de correcto y devuelve el resultado en formato de tabla.

az pipelines runs list --status completed --result succeeded --top 3 --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  ------
125       20200124.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 18:56:10.067588  manual
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual
122       20200123.1  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:48:05.574742  manual

Mostrar detalles de ejecución de canalización

Muestre los detalles de una ejecución de canalización en el proyecto con el comando az pipelines runs show. Para empezar, consulte Introducción a la CLI de Azure DevOps.

az pipelines runs show --id
                       [--open]
                       [--org]
                       [--project]

Parámetros

  • id: obligatorio. Identificador de la ejecución de canalización.
  • open: opcional. Abre la página de resultados de la compilación en el explorador web.
  • org: la URL de la organización de Azure DevOps. Puede configurar la organización predeterminada mediante az devops configure -d organization=ORG_URL. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config. Ejemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: el nombre o identificador del proyecto. El proyecto predeterminado se puede configurar mediante az devops configure -d project=NAME_OR_ID. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config.

Ejemplo

El siguiente comando muestra los detalles de la ejecución de la canalización con el identificador 123 y devuelve los resultados en formato de tabla. También abre el explorador web en la página de resultados de la compilación.

az pipelines runs show --id 122 --open --output table

Run ID    Number      Status     Result     Pipeline ID    Pipeline Name               Source Branch    Queued Time                 Reason
--------  ----------  ---------  ---------  -------------  --------------------------  ---------------  --------------------------  --------
123       20200123.2  completed  succeeded  12             Githubname.pipelines-java  master           2020-01-23 11:55:56.633450  manual

Adición de una etiqueta a una ejecución de canalización

Agregue una etiqueta a una ejecución de canalización en el proyecto con el comando az pipelines runs tag add . Para empezar, consulte Introducción a la CLI de Azure DevOps.

az pipelines runs tag add --run-id
                          --tags
                          [--org]
                          [--project]

Parámetros

  • run-id: obligatorio. Identificador de la ejecución de canalización.
  • tags: obligatorio. Etiquetas que se van a agregar a la ejecución de canalización (valores separados por comas).
  • org: la URL de la organización de Azure DevOps. Puede configurar la organización predeterminada mediante az devops configure -d organization=ORG_URL. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config. Ejemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: el nombre o identificador del proyecto. El proyecto predeterminado se puede configurar mediante az devops configure -d project=NAME_OR_ID. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config.

Ejemplo

El siguiente comando agrega la etiqueta YAML a la ejecución de canalización con el identificador 123 y devuelve el resultado en formato JSON.

az pipelines runs tag add --run-id 123 --tags YAML --output json

[
  "YAML"
]

Enumerar etiquetas de ejecución de canalización

Enumere las etiquetas de una ejecución de canalización en el proyecto con el comando az pipelines runs tag list. Para empezar, consulte Introducción a la CLI de Azure DevOps.

az pipelines runs tag list --run-id
                           [--org]
                           [--project]

Parámetros

  • run-id: obligatorio. Identificador de la ejecución de canalización.
  • org: la URL de la organización de Azure DevOps. Puede configurar la organización predeterminada mediante az devops configure -d organization=ORG_URL. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config. Ejemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: el nombre o identificador del proyecto. El proyecto predeterminado se puede configurar mediante az devops configure -d project=NAME_OR_ID. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config.

Ejemplo

El siguiente comando muestra las etiquetas para la ejecución de canalización con el identificador 123 y devuelve el resultado en formato de tabla.

az pipelines runs tag list --run-id 123 --output table

Tags
------
YAML

Eliminación de etiquetas de la ejecución de canalización

Elimine una etiqueta de una ejecución de canalización en el proyecto con el comando az pipelines runs tag delete. Para empezar, consulte Introducción a la CLI de Azure DevOps.

az pipelines runs tag delete --run-id
                             --tag
                             [--org]
                             [--project]

Parámetros

  • run-id: obligatorio. Identificador de la ejecución de canalización.
  • tag: obligatorio. Etiqueta que se va a eliminar de la ejecución de la canalización.
  • org: la URL de la organización de Azure DevOps. Puede configurar la organización predeterminada mediante az devops configure -d organization=ORG_URL. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config. Ejemplo: --org https://dev.azure.com/MyOrganizationName/.
  • project: el nombre o identificador del proyecto. El proyecto predeterminado se puede configurar mediante az devops configure -d project=NAME_OR_ID. Es obligatorio si no está configurado como predeterminado o seleccionado mediante git config.

Ejemplo

El siguiente comando elimina la etiqueta YAML de la ejecución de canalización con el identificador 123.

az pipelines runs tag delete --run-id 123 --tag YAML