Descripción de Acciones de GitHub

7 minutos

Puede automatizar los pasos del proceso de implementación usando un flujo de trabajo. Cada vez que realiza un cambio en el código y lo confirma en el repositorio de Git, el flujo de trabajo ejecuta el proceso predefinido. Un flujo de trabajo puede comprobar si el código de Bicep cumple los estándares de calidad y, a continuación, automatiza las acciones para implementar los recursos en Azure. El proceso se especifica en una definición de flujo de trabajo que usted crea.

Acciones de GitHub es una característica de GitHub. GitHub hospeda también los repositorios de Git que usa para almacenar y compartir código con otros colaboradores. Una vez que el código de Bicep se almacena en GitHub, Acciones de GitHub puede acceder a ese código para automatizar los procesos de implementación. En esta unidad, conocerá Acciones de GitHub.

¿Qué es un flujo de trabajo?

Un flujo de trabajo es un proceso repetible configurable que se define en un archivo que se usa para probar e implementar el código. Un flujo de trabajo consta de todos los pasos que debe ejecutar, en orden correcto.

Cuando se trabaja con Acciones de GitHub, la configuración del flujo de trabajo se define en un archivo de YAML. Dado que el archivo de YAML de un flujo de trabajo es un archivo de código, se almacena con el código de Bicep en el repositorio de Git, en una carpeta con el nombre .github/workflows. Un archivo de YAML es un archivo de texto estructurado, similar al de Bicep. Puede crear y editar un archivo de YAML con cualquier editor de texto. En este módulo, usará Visual Studio Code como editor. La interfaz web GitHub proporciona herramientas que puede usar para ver y editar el archivo de YAML de flujo de trabajo, colaborar en la definición del flujo de trabajo y administrar diferentes versiones del archivo de flujo de trabajo mediante confirmaciones y ramas.

Ejecutores

Hasta ahora, ha implementado los archivos de Bicep desde el equipo local. Después de escribir una plantilla de Bicep, puede implementarla en Azure mediante la CLI de Azure o Azure PowerShell. Estas herramientas usan los recursos del equipo para enviar la plantilla a Azure. Utilizan su identidad personal para autenticarse en Azure y comprobar que tiene los permisos necesarios para implementar los recursos.

Un flujo de trabajo también necesita acceso a un equipo o GPU con el sistema operativo y la plataforma de hardware correctos para poder ejecutar las acciones de implementación. Acciones de GitHub usa ejecutores, que son equipos que están configurados para ejecutar pasos de implementación para un flujo de trabajo. Cada ejecutor tiene ya las herramientas de Bicep y Azure que usó en módulos anteriores, por lo que puede hacer las mismas cosas que usted hace desde su equipo. En lugar de que una persona ejecute los comandos, el servicio Acciones de GitHub le indica al ejecutor que realice los pasos que usted ha definido en el archivo de YAML de flujo de trabajo.

Acciones de GitHub proporciona varios tipos de ejecutores para diferentes sistemas operativos, como Linux o Windows, y diferentes conjuntos de herramientas. GitHub administra estos ejecutores para que no tenga que mantener ninguna infraestructura de proceso para ellos. A veces, a los ejecutores se les llama ejecutores hospedados en GitHub o ejecutores hospedados, porque se hospedan en nombre del usuario. Cuando se ejecuta el flujo de trabajo, se crea automáticamente un ejecutor hospedado. Cuando finaliza la ejecución del flujo de trabajo, el ejecutor hospedado se elimina automáticamente. No puede acceder directamente a los ejecutores hospedados, por lo que es importante que el flujo de trabajo contenga todos los pasos necesarios para implementar la solución.

Diagram that shows a workflow that runs on a runner.

Nota:

Puede crear un ejecutor personalizado denominado ejecutor autohospedado. Puede crearlo si hay un software específico que deba ejecutar como parte del flujo de trabajo o si necesita controlar con exactitud la configuración del ejecutor. En este módulo, no se tratan los ejecutores autohospedados, pero se proporciona un vínculo para obtener más información en la sección Resumen.

Desencadenadores

Se utiliza un desencadenador para indicar a Acciones de GitHub cuándo debe ejecutarse el flujo de trabajo. Puede elegir entre varios tipos de desencadenadores. Por ahora, utilice un desencadenador manual para indica a Acciones de GitHub cuándo debe empezar a ejecutar el flujo de trabajo. Más adelante en el módulo, conocerá otros tipos de desencadenadores.

Diagram that shows a trigger initiating a workflow.

Pasos

Un paso representa una operación que el flujo de trabajo realiza. Es similar a un comando individual que ejecute en Bash o PowerShell. Para la mayoría de las implementaciones, se ejecutan varios pasos en una secuencia. Defina la secuencia y todos los detalles de cada paso en el archivo de YAML del flujo de trabajo.

Acciones de GitHub ofrece dos tipos de pasos:

Pasos de ejecución: Utilice un paso de ejecución para ejecutar un único comando o una secuencia de comandos en Bash, PowerShell o el shell de comandos de Windows.
Pasos de acción: Un paso de acción es una forma cómoda de acceder a muchas características diferentes sin escribir instrucciones de scripts. Por ejemplo, hay una tarea integrada para implementar archivos de Bicep en Azure. Cualquiera puede escribir una acción y compartirla con otros usuarios. Hay disponible un amplio conjunto de tareas comerciales y de código abierto.

Algunas personas prefieren usar instrucciones de scripts en lugar de acciones, porque ofrecen más control sobre lo que se ejecuta. Otras personas prefieren usar acciones para no tener que escribir y administrar scripts. En este módulo, usamos una combinación de ambos enfoques.

Trabajos

En Acciones de GitHub, un trabajo representa un conjunto ordenado de pasos. Siempre se tiene al menos un trabajo en un flujo de trabajo y, cuando se crean implementaciones complejas, es habitual tener más de un trabajo.

Nota:

Puede establecer que cada trabajo se ejecute en un ejecutador diferente. La ejecución de trabajos en ejecutadores diferentes resulta útil cuando se compilan e implementan soluciones que necesitan usar sistemas operativos diferentes en distintas partes del flujo de trabajo.

Por ejemplo, supongamos que va a crear una aplicación de iOS y el servicio de back-end correspondiente. Puede tener un trabajo que se ejecute en un ejecutador de macOS para crear la aplicación de iOS y otro trabajo que se ejecute en un ejecutador de Ubuntu o Windows para crear el back-end. Incluso puede indicar al flujo de trabajo que ejecute los dos trabajos simultáneamente, lo que acelera la ejecución del flujo de trabajo.

Diagram that shows a workflow with two steps, both within one job.

Ejemplo de flujo de trabajo básico

Ahora que ya conoce los aspectos básicos de Acciones de GitHub, veamos una definición de flujo de trabajo sencilla en YAML:

name: learn-github-actions

on: [workflow_dispatch]

jobs:
  say-hello:
    runs-on: ubuntu-latest
    steps:
      - name: 'Run a one-line command'
        run: echo "hello from GitHub Actions"
      - name: 'Run a multi-line command'
        run: |
          echo "We'll add more steps soon."
          echo "For example, we'll add our Bicep deployment step."

Veamos cada parte del archivo en detalle:

name es el nombre del flujo de trabajo. El nombre se muestra en la interfaz web de GitHub.
on le indica al flujo de trabajo cuándo debe ejecutarse. En este caso, on: [workflow_dispatch] le indica a Acciones de GitHub que quiere desencadenar manualmente el flujo de trabajo.
jobs agrupa todos los trabajos del flujo de trabajo.
say-hello es el nombre del primer y único trabajo de este flujo de trabajo.
runs-on le indica al flujo de trabajo qué ejecutor debe usar para ejecutar el trabajo. En este ejemplo, el flujo de trabajo se ejecuta en un sistema operativo Ubuntu que pertenece a un grupo de ejecutores hospedados en GitHub.
steps enumera la secuencia de pasos que deben ejecutarse en el trabajo. El archivo de YAML de ejemplo tiene dos pasos. Los dos pasos ejecutan un script sencillo para mostrar un texto. Cada paso tiene un valor de name, que es de lenguaje natural. Verá el nombre en los registros de flujo de trabajo. Para crear un paso de script multilínea, use una barra vertical (|) como se muestra en el ejemplo. Después de ejecutarse el paso, verá las salidas en el registro del flujo de trabajo.

Importante

En los archivos YAML, la sangría es importante. Observe el ejemplo de YAML. A algunas líneas del código de YAML se les aplica una sangría de dos o cuatro espacios. Si no aplica la sangría correctamente en el archivo, Acciones de GitHub no puede interpretarlo. Visual Studio Code ayuda a buscar y corregir errores de sangría en el archivo de YAML.