¿De qué forma las Acciones de GitHub automatizan las tareas de desarrollo?

Completado

Aquí se presentan acciones y flujos de trabajo de GitHub. Aprenderá los tipos de acciones que puede usar y dónde encontrarlos. También verá ejemplos de estos tipos de acciones y cómo encajan en un flujo de trabajo.

Reducción del tiempo que transcurre entre la idea y la implementación gracias a GitHub

GitHub está diseñado para ayudar a los equipos de desarrolladores y a los ingenieros de DevOps a crear e implementar aplicaciones rápidamente. Hay muchas características en GitHub que permiten estas eficiencias, pero generalmente se dividen en una de estas dos categorías:

• Comunicación: considere todas las formas en que GitHub facilita a un equipo de desarrolladores la comunicación sobre el proyecto de desarrollo de software: revisiones de código en solicitudes de incorporación de cambios, incidencias de GitHub, paneles de proyectos, wikis, notificaciones, etc.
• Automatización: Acciones de GitHub permite que el equipo automatice los flujos de trabajo en cada paso del proceso de desarrollo de software, desde la integración hasta la entrega y la implementación. Incluso le permite automatizar la adición de etiquetas a las solicitudes de incorporación de cambios y la comprobación de incidencias y solicitudes de incorporación de cambios obsoletas.

Al combinarse, estas características han permitido a miles de equipos de desarrollo reducir de manera eficaz la cantidad de tiempo que transcurre desde su idea inicial hasta la implementación.

Uso de la automatización de flujo de trabajo para reducir el tiempo de desarrollo

En este módulo, nos centramos en la automatización. Dediquemos un momento a comprender cómo los equipos pueden utilizar la automatización para reducir el tiempo que se tarda en completar un flujo de trabajo típico de desarrollo e implementación.

Considere todas las tareas que deben tener lugar después de que se escriba el código, pero antes de que el código se pueda usar de forma confiable para su finalidad prevista. En función de los objetivos de la organización, es probable que tenga que realizar una o varias de las tareas siguientes:

• Asegurarse de que el código pasa todas las pruebas unitarias.
• Realizar controles de calidad y cumplimiento del código para garantizar que el código fuente cumpla con los estándares de la organización.
• Comprobar el código y sus dependencias para detectar problemas de seguridad conocidos.
• Compile el código mediante la integración del nuevo código fuente de varios colaboradores (potencialmente).
• Asegurarse de que el software pasa las pruebas de integración.
• Especifique la versión de la nueva compilación.
• Entregar los nuevos archivos binarios a la ubicación adecuada del sistema de archivos.
• Implementar los nuevos archivos binarios en uno o varios servidores.
• Determina si alguna de estas tareas no se cumple y notifica el problema a la persona o equipo adecuado para su resolución.

El reto es realizar estas tareas de manera confiable, sistemática y sostenible. Este proceso es un trabajo ideal para la automatización del flujo de trabajo. Si ya confía en GitHub, es probable que quiera configurar la automatización del flujo de trabajo mediante Acciones de GitHub.

¿Qué son las Acciones de GitHub?

Las Acciones de GitHub son scripts empaquetados para automatizar tareas en un flujo de trabajo de desarrollo de software en GitHub. Puede configurar GitHub Actions para desencadenar flujos de trabajo complejos que se adapten las necesidades de su organización. El desencadenante puede producirse cada vez que los desarrolladores comprueban un nuevo código fuente en una rama específica, a intervalos cronometrados o manualmente. El resultado es un flujo de trabajo automatizado confiable y sostenible, que supone una disminución significativa del tiempo de desarrollo.

¿Dónde se pueden encontrar las Acciones de GitHub?

Las Acciones de GitHub son scripts que se adhieren a un formato de datos yml. Cada repositorio tiene una pestaña Acciones que proporciona una manera rápida y sencilla de empezar a configurar el primer script. Si ve un flujo de trabajo que cree que podría ser un buen punto de partida, solo tiene que seleccionar el botón Configurar para agregar el script y comenzar a editar el archivo YML de origen.

Sin embargo, más allá de las Acciones de GitHub destacadas en la pestaña Acciones, puede:

• Buscar Acciones de GitHub en el Marketplace de GitHub. El Marketplace de GitHub permite detectar y comprar herramientas que amplían el flujo de trabajo.
• Buscar proyectos de código abierto. Por ejemplo, la organización Acciones de GitHub presenta muchos repositorios populares de código abierto que contienen Acciones de GitHub que puede usar.
• Escriba sus propias Acciones de GitHub desde cero. Puede convertirlos en código abierto o incluso publicarlos en GitHub Marketplace.

Uso de Acciones de GitHub de código abierto

Muchas Acciones de GitHub son de código abierto y están disponibles para todos los usuarios que quieran usarlas. Pero como sucede con cualquier software de código abierto, debe comprobarlas con atención antes de usarlas en el proyecto. De forma similar a los estándares comunitarios recomendados para el software de código abierto, como incluir un archivo LÉAME, un código de conducta, un archivo de contribución y plantillas de incidencias, puede seguir estas recomendaciones al usar GitHub Actions.

• Revise el archivo action.yml de la acción para ver las entradas y salidas, y para asegurarse de que el código hace lo que dice que hace.
• Compruebe si la acción está en el Marketplace de GitHub. Esta comprobación merece la pena, incluso si una acción no tiene que estar en Marketplace de GitHub para que sea válida.
• Compruebe si la acción está verificada en el Marketplace de GitHub. La comprobación significa que GitHub aprobó el uso de esta acción. Sin embargo, debe revisarla igualmente antes de usarla.
• Incluya la versión de la acción que use mediante la especificación de una referencia de Git, SHA o etiqueta.

Tipos de acciones de GitHub

Hay tres tipos de acciones de GitHub: acciones de contenedor, acciones de JavaScript y acciones de composición.

En las acciones de contenedor, el entorno forma parte del código de la acción. Estas acciones solo se pueden ejecutar en un entorno de Linux hospedado por GitHub. Las acciones de contenedor admiten muchos lenguajes diferentes.

Las acciones de JavaScript no incluyen el entorno en el código. Debe especificar el entorno para ejecutar estas acciones. Puede ejecutar estas acciones en una máquina virtual (máquina virtual) en la nube o en el entorno local. Las acciones de JavaScript admiten entornos de Linux, macOS y Windows.

Las acciones de composición permiten combinar varios pasos de flujo de trabajo dentro de una acción. Por ejemplo, puedes utilizar esta característica para agrupar comandos de ejecución múltiples en una acción y luego tener un flujo de trabajo que ejecute estos comandos agrupados como un paso simple utilizando dicha acción.

Anatomía de una acción de GitHub

Este es un ejemplo de una acción que realiza un checkout de un repositorio de Git. Esta acción, actions/checkout@v1, forma parte de un paso de un flujo de trabajo. En este paso también se compila el código Node.js desprotegido. Hablaremos sobre los flujos de trabajo, los trabajos y los pasos en la sección siguiente.

steps:
  - uses: actions/checkout@v1
  - name: npm install and build webpack
    run: |
      npm install
      npm run build

Supongamos que quiere utilizar una acción de contenedor para ejecutar código en contenedor. Su acción podría tener este aspecto:

name: "Hello Actions"
description: "Greet someone"
author: "octocat@github.com"

inputs:
    MY_NAME:
      description: "Who to greet"
      required: true
      default: "World"

runs:
    uses: "docker"
    image: "Dockerfile"

branding:
    icon: "mic"
    color: "purple"

Observe la sección inputs. Aquí se obtiene el valor de una variable denominada MY_NAME. Esta variable se establece en el flujo de trabajo que ejecuta esta acción.

En la sección runs, especifique docker en el atributo uses. Al establecer este valor, debe proporcionar la ruta de acceso al archivo de imagen de Docker. En este caso, Dockerfile. Aquí no se tratan los detalles de Docker, pero si quiere obtener más información, consulte el módulo Introducción a los contenedores de Docker .

En la última sección, branding, se personaliza tu acción en GitHub Marketplace si decides publicarla allí.

Puede encontrar una lista completa de los metadatos de la acción en Sintaxis de metadatos para Acciones de GitHub.

¿Qué es un flujo de trabajo de Acciones de GitHub?

Un flujo de trabajo de Acciones de GitHub es un proceso que se configura en el repositorio para automatizar las tareas del ciclo de vida de desarrollo de software, lo que incluye Acciones de GitHub. Con un flujo de trabajo, puede compilar, probar, empaquetar, publicar e implementar cualquier proyecto en GitHub.

Para crear un flujo de trabajo, agregue acciones a un archivo .yml en el directorio .github/workflows del repositorio de GitHub.

En el ejercicio que aparece, el archivo de flujo de trabajo main.yml tiene un aspecto similar al de este ejemplo:

name: A workflow for my Hello World file
on: push
jobs:
  build:
    name: Hello world action
    runs-on: ubuntu-latest
    steps:
    - uses: actions/checkout@v1
    - uses: ./action-a
      with:
        MY_NAME: "Mona"

Observe el on: atributo , su valor es un desencadenador para especificar cuándo se ejecuta este flujo de trabajo. En este caso, desencadena una ejecución cuando se produce un evento push en tu repositorio. Puede especificar eventos únicos como on: push, una matriz de eventos como on: [push, pull_request] o un mapa de configuración de eventos que programe un flujo de trabajo o restrinja la ejecución de un flujo de trabajo a cambios de bifurcaciones, etiquetas o archivos específicos. Es posible que el mapa tenga un aspecto similar a este:

on:
  # Trigger the workflow on push or pull request,
  # but only for the main branch
  push:
    branches:
      - main
  pull_request:
    branches:
      - main
  # Also trigger on page_build, as well as release created events
  page_build:
  release:
    types: # This configuration doesn't affect the page_build event above
      - created

Un evento se desencadena en todos los tipos de actividad del evento a menos que especifique el tipo o los tipos. Para obtener una lista completa de los eventos y sus tipos de actividad, vea: Eventos que desencadenan flujos de trabajo en la documentación de GitHub.

Un flujo de trabajo debe tener al menos un trabajo. Un trabajo es una sección del flujo de trabajo asociada a un ejecutor. Un ejecutor puede estar hospedado en GitHub o autohospedado, y el trabajo se puede ejecutar en una máquina o en un contenedor. Especifique el ejecutor con el atributo runs-on:. Aquí, estás indicando al flujo de trabajo que ejecute este trabajo en ubuntu-latest.

Cada trabajo tiene pasos para completarse. En el ejemplo, el paso usa la acción actions/checkout@v1 para extraer el repositorio. Lo interesante es el valor uses: ./action-a, que es la ruta a la acción de contenedor que se crea en un archivo action.yml.

La última parte de este archivo de flujo de trabajo establece el valor de la variable MY_NAME para este flujo de trabajo. Recuerde que la acción de contenedor tomó una entrada llamada MY_NAME.

Para más información sobre la sintaxis del flujo de trabajo, vea Sintaxis de flujo de trabajo para Acciones de GitHub.

Hacer referencia a acciones en flujos de trabajo

Al crear flujos de trabajo en Acciones de GitHub, puede hacer referencia a acciones de varios orígenes. Estas acciones se pueden usar para automatizar tareas en los flujos de trabajo. A continuación se muestran los orígenes principales en los que los flujos de trabajo pueden hacer referencia a acciones:

1. Imagen de contenedor de Docker publicada en Docker Hub
   Los flujos de trabajo pueden hacer referencia a acciones publicadas como imágenes de contenedor de Docker en Docker Hub. Estas acciones están contenedorizadas e integran todas las dependencias necesarias para llevar a cabo la acción. Para usar esta acción, especifique la imagen de Docker en el uses atributo del paso de flujo de trabajo. Por ejemplo:

   steps:
     - name: Run a Docker action
       uses: docker://<docker-image-name>:<tag>
   

2. Cualquier repositorio público
   Las acciones hospedadas en repositorios públicos se pueden referenciar directamente en los flujos de trabajo. Estas acciones son accesibles para cualquier persona y se pueden usar especificando el nombre y la versión del repositorio (Git ref, SHA o tag) en el uses atributo . Por ejemplo:

   steps:
     - name: Use a public action
       uses: actions/checkout@v3
   

[IMPORTANTE]

Para mejorar la seguridad, use un SHA de confirmación completa al hacer referencia a acciones, no solo una etiqueta como @v3.
Esto garantiza que el flujo de trabajo siempre use el mismo código exactamente, incluso si la acción se actualiza o cambia más adelante.
Ejemplo: uses: actions/checkout@c2c1744e079e0dd11c8e0af4a96064ca4f6a2e9e

3. El mismo repositorio que el archivo de flujo de trabajo
   Puede hacer referencia a acciones almacenadas en el mismo repositorio que el archivo de flujo de trabajo. Esta característica es útil para acciones personalizadas específicas del proyecto. Para hacer referencia a estas acciones, use una ruta de acceso relativa al directorio de la acción. Por ejemplo:

   steps:
     - name: Use a local action
       uses: ./path-to-action
   

Para más información, consulte guía de protección de seguridad para Acciones de GitHub.

4. Un marketplace empresarial
   Si su organización usa GitHub Enterprise, puede hacer referencia a acciones desde el marketplace privado de la empresa. Estas acciones son seleccionadas y gestionadas por su organización, lo que garantiza el cumplimiento de los estándares internos. Por ejemplo:

   steps:
     - name: Use an enterprise marketplace action
       uses: enterprise-org/action-name@v1
   

Nota:

• También se puede hacer referencia a acciones en repositorios privados, pero requieren la autenticación y los permisos adecuados.
• Al hacer referencia a acciones, especifique siempre una versión (git ref, SHA o etiqueta) para garantizar la coherencia y evitar cambios inesperados.

Para obtener más información, consulte Hacer referencia a acciones en flujos de trabajo.

Ejecutores hospedados en GitHub y autohospedados

Hemos mencionado brevemente a los corredores como relacionados con un trabajo. Un ejecutor es simplemente un servidor que tiene instalada la aplicación de ejecutor de Acciones de GitHub. En el ejemplo de flujo de trabajo anterior, había un runs-on: ubuntu-latest atributo dentro del bloque de trabajos, que le dijo al flujo de trabajo que el trabajo se va a ejecutar mediante el ejecutor hospedado en GitHub que se ejecuta en el ubuntu-latest entorno.

En lo que respecta a los ejecutores, hay dos opciones entre las que elegir: Ejecutores hospedados en GitHub o ejecutores autohospedados. Si usa un ejecutor hospedado en GitHub, cada trabajo se ejecuta en una nueva instancia de un entorno virtual. El tipo de ejecutor hospedado en GitHub que defina, runs-on: {operating system-version} especifica ese entorno. Con los ejecutores autohospedados, debe aplicar la etiqueta de autohospedado, su sistema operativo y la arquitectura del sistema. Por ejemplo, un ejecutor autohospedado con un sistema operativo Linux y una arquitectura ARM32 tendría el siguiente aspecto: runs-on: [self-hosted, linux, ARM32].

Cada tipo de ejecutor tiene sus ventajas, pero los ejecutores hospedados en GitHub ofrecen una manera más rápida y sencilla de ejecutar los flujos de trabajo, aunque con opciones limitadas. Los ejecutores autohospedados son una manera muy configurable de ejecutar flujos de trabajo en su propio entorno local personalizado. Puede ejecutar ejecutores autohospedados en el entorno local o en la nube. También puede utilizar ejecutores autohospedados para crear una configuración de hardware personalizada con más potencia de procesamiento o memoria. Este tipo de configuración ayuda a ejecutar trabajos más grandes, instalar software disponible en la red local y elegir un sistema operativo no ofrecido por los ejecutores hospedados en GitHub.

Acciones de GitHub puede tener límites de uso

Acciones de GitHub tiene algunos límites de uso, según el plan de GitHub y si el ejecutor está hospedado en GitHub o autohospedado. Para obtener más información sobre los límites de uso, consulte Límites de uso, facturación y administración en la documentación de GitHub.

Ejecutores más grandes hospedados en GitHub

GitHub ofrece ejecutores más grandes para flujos de trabajo que requieren más recursos. Estos ejecutores están hospedados en GitHub y proporcionan un mayor espacio en la CPU, la memoria y el disco en comparación con los ejecutores estándar. Están diseñados para controlar los flujos de trabajo que consumen muchos recursos de forma eficaz, lo que garantiza un rendimiento óptimo para las tareas exigentes.

Tamaños y etiquetas del ejecutor

Los ejecutores más grandes están disponibles en varias configuraciones, lo que proporciona vCPU mejoradas, RAM y almacenamiento SSD para satisfacer diversos requisitos de flujo de trabajo. Estas configuraciones son ideales para escenarios como:

• Compilar código base de gran tamaño con archivos de código fuente extensos.
• Ejecutar conjuntos de pruebas completos, incluidas las pruebas de integración y de un extremo a otro.
• Procesamiento de grandes conjuntos de datos para el análisis de datos o las tareas de aprendizaje automático.
• Compilar aplicaciones con dependencias complejas o salidas binarias grandes.
• Realizar simulaciones de alto rendimiento o modelado computacional.
• Ejecutar codificación de vídeo, representación u otros flujos de trabajo de procesamiento multimedia.

Para usar un ejecutor mayor, especifique la etiqueta de ejecutor deseada en el runs-on atributo del archivo de flujo de trabajo. Por ejemplo, para usar un ejecutor con 16 vCPU y 64 GB de RAM, establecería runs-on: ubuntu-latest-16core.

jobs:
  build:
    runs-on: ubuntu-latest-16core
    steps:
      - uses: actions/checkout@v2
      - name: Build project
        run: make build

Estos ejecutores más grandes mantienen la compatibilidad con los flujos de trabajo existentes mediante la inclusión de las mismas herramientas preinstaladas que los ejecutores estándar ubuntu-latest .

Para más información sobre los tamaños de ejecutor para ejecutores más grandes, consulte la documentación de GitHub.

Administración de ejecutores de mayor capacidad

GitHub proporciona herramientas para administrar ejecutores más grandes de forma eficaz, lo que garantiza un uso óptimo de los recursos y la administración de costos. Estos son algunos aspectos clave de la gestión de corredores más grandes:

Supervisión del uso

Puede supervisar el uso de ejecutores más grandes a través de la página de uso de Acciones de GitHub en la configuración del repositorio o de la organización. En esta página se proporciona información sobre el número de trabajos ejecutados, el tiempo de ejecución total y los costos asociados.

Administración del acceso

Para controlar el acceso a ejecutores más grandes, puede configurar directivas de nivel de organización o repositorio. Esta configuración garantiza que solo los flujos de trabajo o equipos autorizados puedan usar estos ejecutores de recursos elevados.

Administración de costos

Los ejecutores más grandes incurren en costes adicionales en función de su uso. Para administrar los costos, tenga en cuenta las sugerencias siguientes:

• Utilice procesadores más grandes solo para flujos de trabajo que requieran recursos elevados.
• Reduzca el tiempo de ejecución mediante la optimización de flujos de trabajo.
• Supervise los detalles de facturación periódicamente para realizar un seguimiento de los gastos.

Escalado de flujos de trabajo

Si los flujos de trabajo requieren un uso frecuente de ejecutores más grandes, contemple la escalabilidad de estrategias como:

• Uso de ejecutores autohospedados para cargas de trabajo predecibles.
• Dividir flujos de trabajo en trabajos más pequeños para distribuir la carga entre ejecutores estándar.