Secuencia de ejecución de canalización

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

Cuando se ejecuta una canalización, suceden muchas cosas en primer lugar. Aunque a menudo no necesitará conocerlos, en ocasiones resulta útil tener una idea general. En un nivel alto, Azure Pipelines hará lo siguiente:

• Procesar la canalización
• Solicitud de uno o varios agentes para ejecutar trabajos
• Entrega de trabajos a agentes y recopilación de los resultados

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

• Prepararse para el trabajo
• Ejecución de cada paso del trabajo
• Informe de los resultados Azure Pipelines

Los trabajos pueden realizarse correctamente, producir un error o cancelarse. También hay situaciones en las que un trabajo puede no completarse. Comprender cómo sucede esto puede ayudarle a solucionar problemas.

Vamos a dividir cada acción una por una.

Procesar la canalización

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

1. En primer lugar, expanda plantillas y evalúe las expresiones de plantilla.
2. A continuación, evalúe las dependencias en el nivel de fase para elegir las primeras fases que se ejecutarán.
3. Para cada fase seleccionada para ejecutarse, suceden dos cosas:
   • Todos los recursos usados en todos los trabajos se recopilan y validan para que se ejecute la autorización.
   • Evalúe las dependencias en el nivel de trabajo para elegir los primeros trabajos que se ejecutarán.
4. Para cada trabajo seleccionado para ejecutarse, expanda las configuraciones múltiples ( o en strategy: parallel 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 válido.

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

Esta ordenación ayuda a responder a una pregunta común: ¿por qué no puedo usar determinadas variables en los parámetros de la plantilla? El paso 1, 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 nombres de entorno o conexión de servicio? Los recursos se autorizan antes de que una fase pueda empezar a ejecutarse, por lo que las variables de nivel de fase y trabajo no están disponibles. Se pueden usar variables de nivel de canalización, pero solo aquellas incluidas explícitamente en la canalización. Los grupos de variables son en sí mismos un recurso sujeto a autorización, por lo que sus datos tampoco están disponibles al comprobar la autorización de recursos.

Solicitud de un agente

Siempre Azure Pipelines necesita ejecutar un trabajo, pedirá al grupo un agente. (Los trabajos de servidor son una excepción, ya que se ejecutan en Azure Pipelines servidor). Los grupos de agentesauto-hospedados y hospedados por Microsoft 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. Suma 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 en una ranura para liberarla.

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

Todos los agentes del grupo de Microsoft son máquinas virtuales nuevas y 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 auto hospedadas

De forma similar al grupo hospedado por Microsoft,el servicio comprueba primero los trabajos paralelos de la organización. Suma todos los trabajos en ejecución en todos los agentes auto-hospedados y lo compara con el número de trabajos paralelos adquiridos. Si no hay ranuras paralelas disponibles, el trabajo tiene que esperar en una ranura para liberarla.

Una vez que hay disponible una ranura paralela, el grupo auto-hospedado se examina para un agente compatible. Los agentes auto-hospedados ofrecen funcionalidades, que son cadenas que indican que se ha instalado un software determinado o que se ha configurado la configuración. 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 seguirá esperando. Si no hay ningún agente en el grupo cuyas funcionalidades coincidan con las demandas, se producirá un error en el trabajo.

Los agentes auto-hospedados normalmente se reutilizan de la ejecución a la ejecución. Esto significa que un trabajo de canalización puede tener efectos secundarios: la actualización de cachés, la mayoría de las confirmaciones ya están disponibles en el repositorio local, y así sucesivamente.

Preparación para ejecutar un trabajo

Una vez que un agente ha aceptado un trabajo, tiene que realizar algún trabajo de preparación. 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 el disco para contener el código fuente, los artefactos y las salidas que se usan en la ejecución. A continuación, comienza a ejecutar los pasos.

Ejecución de cada paso

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

Las tareas implementan los pasos. Las propias tareas se implementan como scripts 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 de acceso del sistema y crear nuevas variables de canalización.

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

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 paso siguiente. Para establecer una nueva variable myVar con un valor de , un script puede hacer lo myValue siguiente:

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

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

Informe y recopilación de resultados

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

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, toda la salida del paso 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 resultadosde 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 realizarán correctamente con problemas o con errores, se actualizará el estado del trabajo. El trabajo siempre refleja el resultado "peor" de cada uno de sus pasos: si se produce un error en un paso, también se produce un error en el trabajo.

Antes de ejecutar un paso, el agente comprobará la condición de ese paso para determinar si debe ejecutarse. De forma predeterminada, un paso solo se ejecutará cuando el estado del trabajo se haya ejecutado correctamente o se haya ejecutado 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 posterior no puede guardar el trabajo de errores; los trabajos nunca pueden volver al éxito después de entrar en error.

Tiempos de espera y desconexiones

Cada trabajo tiene un tiempo de espera. Si el trabajo no se ha completado en el tiempo especificado, 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 informado de que el trabajo se ha detenido, el servidor marcará el trabajo como un error.

Dado 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 volver a intentar la canalización.

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]

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

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

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

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

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

[
  "YAML"
]

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

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

Tags
------
YAML

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

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