Caché, uso compartido y depuración de flujos de trabajo

En esta unidad, aprenderá a optimizar el rendimiento, pasar datos entre trabajos y solucionar problemas de flujos de trabajo mediante registros y tokens.

Para implementar este proceso, aprenderá a:

• Almacenar en caché las dependencias para flujos de trabajo más rápidos.
• Pasar datos de artefactos entre trabajos.
• Habilitar el registro de depuración para flujos de trabajo.
• Acceda a los registros de flujo de trabajo desde la interfaz de usuario de GitHub y la API REST.
• Usar tokens de instalación para la autenticación de aplicaciones de GitHub.

Dependencias de caché con la acción de caché

Al crear un flujo de trabajo, a menudo debe reutilizar las mismas salidas o descargar dependencias de una ejecución a otra. En lugar de descargar estas dependencias una y otra vez, puede almacenarlas en caché para que el flujo de trabajo se ejecute de forma más rápida y eficaz. El almacenamiento en caché de dependencias reduce el tiempo necesario para ejecutar determinados pasos en un flujo de trabajo, ya que los trabajos de los ejecutores hospedados en GitHub se inician en un entorno virtual limpio cada vez.

Para almacenar en caché las dependencias de un trabajo, use la acción cache de GitHub. Esta acción recupera una caché que se identifica mediante una clave única que debe proporcionar. Cuando la acción encuentra la caché, recupera los archivos almacenados en caché en la ruta de acceso que configure. Para usar la cache acción, debe establecer algunos parámetros específicos:

steps:
  - uses: actions/checkout@v2

  - name: Cache NPM dependencies
    uses: actions/cache@v2
    with:
      path: ~/.npm
      key: ${{ runner.os }}-npm-cache-${{ hashFiles('**/package-lock.json') }}
      restore-keys: |
        ${{ runner.os }}-npm-cache-

En el ejemplo anterior, path se establece en ~/.npm y key incluye el sistema operativo del ejecutor y el hash SHA-256 del archivo package-lock.json. La adición de un id. como prefijo a la clave (npm-cache en este ejemplo) es útil cuando se usa la reserva restore-keys y hay varias cachés.

Paso de datos de artefactos entre trabajos

De forma similar a la idea de almacenar en caché las dependencias dentro del flujo de trabajo, puede pasar datos entre trabajos dentro del mismo flujo de trabajo. Puede pasar los datos utilizando las acciones upload-artifact y download-artifact. Para poder ejecutarse, los trabajos que dependen de los artefactos de un trabajo anterior deben esperar a que el trabajo anterior se complete correctamente. Este enfoque es útil si tiene una serie de trabajos que deben ejecutarse secuencialmente en función de los artefactos cargados desde un trabajo anterior. Por ejemplo, job_2 necesita job_1 mediante la sintaxis needs: job_1.

name: Share data between jobs
on: push
jobs:
  job_1:
    name: Upload File
    runs-on: ubuntu-latest
    steps:
      - run: echo "Hello World" > file.txt
      - uses: actions/upload-artifact@v2
        with:
          name: file
          path: file.txt

  job_2:
    name: Download File
    runs-on: ubuntu-latest
    needs: job_1
    steps:
      - uses: actions/download-artifact@v2
        with:
          name: file
      - run: cat file.txt

Este ejemplo tiene dos trabajos. job_1 escribe texto en el file.txt archivo. A continuación, usa la acción actions/upload-artifact@v2 para cargar este artefacto y almacenar los datos para su uso futuro en el flujo de trabajo. job_2 requiere job_1 para completar mediante la sintaxis needs: job_1. A continuación, usa la acción actions/download-artifact@v2 para descargar ese artefacto y a continuación, imprimir el contenido de file.txt.

Habilitación del registro de depuración de pasos en un flujo de trabajo

En algunos casos, los registros de flujo de trabajo predeterminados no proporcionan detalles suficientes para diagnosticar por qué se produce un error en una ejecución de flujo de trabajo, un trabajo o un paso específicos. En estos escenarios, puede habilitar más registro de depuración para dos opciones: ejecuciones y pasos. Habilite este registro de diagnóstico estableciendo dos secretos de repositorio que requieren acceso admin al repositorio para true.

• Para habilitar la ejecución del registro de diagnóstico, establezca el ACTIONS_RUNNER_DEBUG secreto en el repositorio que contiene el flujo de trabajo en true.
• Para habilitar el registro de diagnóstico de pasos, establezca en ACTIONS_STEP_DEBUG el secreto true en el repositorio que contiene el flujo de trabajo.

Acceso a los registros de flujo de trabajo en GitHub

Cuando piensa en la automatización exitosa, pretende dedicar la menor cantidad de tiempo a mirar lo que está automatizado y así centrarse en lo que es relevante. Pero a veces las cosas no van según lo planeado y debe revisar lo que sucedió. Ese proceso de depuración puede ser frustrante.

GitHub tiene un diseño estructurado claro para ayudarle a moverse rápidamente entre trabajos mientras conserva el contexto del paso de depuración actual.

Para ver los registros de una ejecución de flujo de trabajo en GitHub:

1. En el repositorio, vaya a la pestaña Acciones .
2. En el panel izquierdo, seleccione el flujo de trabajo.
3. En la lista de ejecuciones de flujo de trabajo, seleccione la ejecución.
4. En Trabajos, seleccione el trabajo.
5. Lea la salida del registro.

Si tiene varias ejecuciones dentro de un flujo de trabajo, puede seleccionar el filtro Estado después de seleccionar el flujo de trabajo y establecerlo en Error para mostrar solo las ejecuciones con errores en ese flujo de trabajo.

Acceso a los registros de flujo de trabajo desde la API REST

Además de ver los registros a través de GitHub, puede usar la API rest de GitHub para ver los registros de ejecuciones de flujo de trabajo, volver a ejecutar flujos de trabajo o incluso cancelar ejecuciones de flujo de trabajo. Para ver el registro de la ejecución de un flujo de trabajo utilizando la API, envíe una GET solicitud al endpoint de registros. Tenga en cuenta que cualquiera con acceso de lectura al repositorio puede usar este punto de conexión. Si el repositorio es privado, debe usar un token de acceso con el ámbito repo.

Por ejemplo, una GET solicitud para ver un registro de ejecución de flujo de trabajo específico sigue esta ruta de acceso:

GET /repos/{owner}/{repo}/actions/runs/{run_id}/logs

Identificación de cuándo usar un token de instalación desde una aplicación de GitHub

Cuando la aplicación de GitHub está instalada en una cuenta, puede autenticarla como una instalación de la aplicación utilizando installation access token para las solicitudes de API REST y GraphQL. Este paso permite que la aplicación acceda a los recursos propiedad de la instalación, suponiendo que a la aplicación se le concedió el acceso y los permisos necesarios del repositorio. Las solicitudes de API REST o GraphQL realizadas por una instalación de una aplicación se atribuyen a la aplicación.

En el ejemplo siguiente, reemplazará INSTALLATION_ACCESS_TOKEN por el token de acceso de instalación:

curl --request GET \
--url "https://api.github.com/meta" \
--header "Accept: application/vnd.github+json" \
--header "Authorization: Bearer INSTALLATION_ACCESS_TOKEN" \
--header "X-GitHub-Api-Version: 2022-11-28"

También puede usar un token de acceso de instalación para autenticarse para el acceso de Git basado en HTTP. La aplicación debe tener el permiso de repositorio Contents. A continuación, puede usar el token de acceso de instalación como contraseña HTTP.

Tú reemplazas TOKEN en el ejemplo con el token de acceso de instalación.

git clone https://x-access-token:TOKEN@github.com/owner/repo.git