Skip to main content

Solucionar problemas en las GitHub Actions de tu empresa

Solucionar problemas comunes que ocurren cuando se utilizan GitHub Actions en GitHub Enterprise Server.

Who can use this feature

Site administrators can troubleshoot GitHub Actions issues and modify GitHub Enterprise Server configurations.

Verificar la salud de las GitHub Actions

Puede comprobar el estado de las GitHub Actions en your GitHub Enterprise Server instance con la utilidad de la línea de comandos ghe-actions-check. Para obtener más información, consulte "Utilidades de la línea de comandos" y "Acceso al shell administrativo (SSH)".

Configurar los ejecutores auto-hospedados cuando utilizas un certificado auto-firmado para GitHub Enterprise Server

Te recomendamos ampliamente que configures el TLS en GitHub Enterprise Server con un certificado que firme una autoridad confiable. Aunque un certificado auto-firmado podría funcionar, se requeriría una configuración adicional para tus ejecutores auto-hospedados y esto no se recomienda para los ambientes productivos. Para obtener más información, consulte "Configuración de TLS".

Instalar el certificado en la máquina ejecutora

Para que un ejecutor auto-hospedado se conecte a GitHub Enterprise Server utilizando un certificado auto-firmado, debes instalarlo en la máquina ejecutora para que la seguridad de la conexión se fortalezca.

Para encontrar los pasos necesarios para instalar un certificado, refiérete a la documentación del sistema operativo de tu ejecutor.

Configurar Node.JS para utilizar el certificado

La mayoría de las acciones se escriben en JavaScript y se ejecutan utilizando Node.js, lo cual no utiliza el almacenamiento del certificado del sistema operativo. Para que la aplicación del ejecutor autohospedado use el certificado, debe establecer la variable de entorno NODE_EXTRA_CA_CERTS en el equipo del ejecutor.

Puede configurar la variable de entorno como una variable de entorno del sistema o declararla en un archivo que se llame .env en el directorio de aplicaciones del ejecutor autohospedado.

Por ejemplo:

NODE_EXTRA_CA_CERTS=/usr/share/ca-certificates/extra/mycertfile.crt

Las variables de ambiente se leen cuando la aplicación ejecutora auto-hospedada inicia, así que debes configurar la variable de ambiente antes de configurar o iniciar la aplicación ejecutora auto-hospedada. Si cambia la configuración de tu certificado, debes reiniciar la aplicación ejecutora auto-hospedada.

Configurar los contenedores de Docker para que utilicen el certificado

Si utilizas las acciones de contenedor de Docker o los contenedores de servicio en tus flujos de trabajo, puede que también necesites instalar el certificado en tu imagen de Docker adicionalmente a configurar la variable de ambiente anterior.

Configurar los ajustes de proxy HTTP para GitHub Actions

Si tienes un servidor proxy HTTP configurado en your GitHub Enterprise Server instance:

  • Debes agregar localhost y 127.0.0.1 a la lista de exclusión de proxy HTTP.

  • Si el cubo BYOS no es enrutable, también debes agregar la dirección URL del cubo a la lista de exclusión.

    Para más información sobre cómo cambiar la configuración del proxy, vea "Configuración de un servidor proxy web saliente".

Si estas opciones no están configuradas correctamente, es posible que reciba errores como Resource unexpectedly moved to https://<IP_ADDRESS> al establecer o cambiar la configuración de GitHub Actions.

Los ejecutores no se conectan a GitHub Enterprise Server con un nombre de host nuevo

Advertencia: No cambie el nombre de host para GitHub Enterprise Server después de la configuración inicial. Cambiar el nombre del host ocasionará un comportamiento inesperado que puede incluir y llegar hasta la interrupción del servicio.

Si despliegas a GitHub Enterprise Server en tu ambiente con un nombre de host nuevo y el nombre de host anterior ya no resuelve hacia tu instancia, los ejecutores auto-hospedados no podrán conectarse al nombre de host anterior y no se ejecutará ningún job.

Necesitarás actualizar la configuración de tus ejecutores auto-hospedados para utilizar el nuevo nombre de host para your GitHub Enterprise Server instance. Cada ejecutor auto-hospedado necesitará alguno de los siguientes procedimientos:

  • En el directorio de aplicaciones del ejecutor autohospedado, edite los archivos .runner y .credentials para reemplazar todas las menciones del nombre de host antiguo por el nuevo nombre de host y, a continuación, reinicie la aplicación del ejecutor autohospedado.
  • Elimina al ejecutor de GitHub Enterprise Server utilizando la IU, y vuelve a agregarlo. Para obtener más información, consulte "Eliminación de ejecutores autohospedados" y "Agregar ejecutores autohospedados".

Jobs atorados y límites de CPU y de memoria de las GitHub Actions

GitHub Actions se compone de varios servicios que se ejecutan en your GitHub Enterprise Server instance. Predeterminadamente, estos servicios se configuran con límites predeterminados de CPU y de memoria que deberían funcionar con la mayoría de las instancias. Sin embargo, los usuarios asiduos de GitHub Actions podrían encesitar ajustar esta configuración.

Puede que estés llegando a los límites de CPU o de memoria si notas que los jobs no están iniciando (aún si hay ejecutores inactivos), o si el progreso del job no se actualiza o cambia en la IU.

1. Verifique el uso total de la memoria y la CPU en la consola de administración

Accede a la consola de administración y utiliza el tablero de monitoreo para inspeccionar las gráficas del total de memoria y de CPU debajo de "Salud del Sistema". Para obtener más información, consulte "Acceso al panel de supervisión".

Si la "Salud del sistema" para el uso total de CPU es cercano a 100%, o si ya no hay memoria disponible restante, entonces your GitHub Enterprise Server instance se está ejecutando al total de su capacidad y necesita escalarse. Para obtener más información, consulte "Aumento de los recursos de CPU o memoria".

2. Verifique el uso de CPU y memoria de los trabajos nómadas en la consola de administración

Si la "Salud del sistema" para el uso total de CPU y memoria están bien, desplázate a la parte inferior de la página, hacia la sección de "Jobs nómadas", y revisa las g´raficas de "Valor porcentual de CPU" y de "Uso de memoria".

Cada sección en estas gráficas corresponde a un servicio. Para los servicios de GitHub Actions, busca:

  • mps_frontend
  • mps_backend
  • token_frontend
  • token_backend
  • actions_frontend
  • actions_backend

Si cualquiera de estos servicios estan cerca de o en 100% de uso de CPU, o si la memoria está cerca de su límite (2 GB, predeterminadamente), entonces el recurso de asignación para estos servicios podría necesitar un aumento. Toma nota de cuáles de los servicios antes descritos están cerca de o en su límite.

3. Incremente la asignación de recursos para los servicios que están en su límite

  1. Ingresa en el shell administrativo utilizando SSH. Para obtener más información, consulte "Acceso al shell administrativo (SSH)".

  2. Ejecuta el siguiente comando para ver qué recursos se encuentran disponibles para su asignación:

    nomad node status -self

    En la salida, encuentra la sección de "Recursos asignados". Es similar al ejemplo siguiente:

    Allocated Resources
    CPU              Memory          Disk
    7740/49600 MHZ   23 GiB/32 GiB   4.4 GiB/7.9 GiB
    

    En el caso de la CPU y la memoria, se muestra cuánto se asigna al total de todos los servicios (el valor izquierdo) y cuánto está disponible (el valor derecho). En el ejemplo anterior, hay 23 GiB de memoria asignada de los 32 GiB totales. Esto significa que hay 9 GiB de memoria disponibles para asignar.

    Advertencia: Tenga cuidado de no asignar más del total de los recursos disponibles o los servicios no podrán iniciarse.

  3. Cambie el directorio a /etc/consul-templates/etc/nomad-jobs/actions:

    cd /etc/consul-templates/etc/nomad-jobs/actions

    En este directorio hay tres archivos que corresponden a los servicios de GitHub Actions descritos anteriormente:

    • mps.hcl.ctmpl
    • token.hcl.ctmpl
    • actions.hcl.ctmpl
  4. Para los servicios en los que identificó una necesidad de ajuste, abra el archivo correspondiente y ubique el grupo resources, que tiene el siguiente aspecto:

    resources {
      cpu = 512
      memory = 2048
      network {
        port "http" { }
      }
    }
    

    Los valores están en MHz para los recursos de CPU y en MB para los recursos de memoria.

    Por ejemplo, para incrementar los límites de recursos en el ejemplo anterior a 1 GHz para el CPU y 4 GB de memoria, cámbialos a:

    resources {
      cpu = 1024
      memory = 4096
      network {
        port "http" { }
      }
    }
    
  5. Guarde y cierre el archivo.

  6. Ejecute ghe-config-apply para aplicar los cambios.

    Al ejecutar ghe-config-apply, si ve una salida como Failed to run nomad job '/etc/nomad-jobs/<name>.hcl', es probable que el cambio haya asignado más recursos de CPU o memoria de la cuenta. Si esto sucede, vuelva a editar los archivos de configuración y reduzca la CPU o memoria asignadas y vuelva a ejecutar ghe-config-apply.

  7. Una vez aplicada la configuración, ejecute ghe-actions-check para comprobar que los servicios de GitHub Actions estén operativos.

Solucionar los fallos cuando el Dependabot active los flujos de trabajo existentes

Después de que configuras las actualizaciones del Dependabot para your GitHub Enterprise Server instance, puedes ver fallas cuando existen flujos de trabajo que se activan con los eventos del Dependabot.

De manera predeterminada, las ejecuciones de flujo de trabajo de GitHub Actions que se activan desde Dependabot a partir de los eventos push, pull_request, pull_request_review o pull_request_review_comment se tratan como si se abrieran desde una bifurcación de repositorio. A diferencia de los flujos de trabajo que activan otros actores, esto significa que recibieron un GITHUB_TOKEN de solo lectura y no tienen acceso a ninguno de los secretos que normalmente se encuentran disponibles. Esto ocasionará que cualquier flujo de trabajo que intente escribir en el repositorio falle cuando los activa el Dependabot.

Hay tres formas de resolver este problema:

  1. Puede actualizar los flujos de trabajo para que ya nos los active Dependabot mediante una expresión como: if: github.actor != 'dependabot[bot]'. Para obtener más información, consulte "Expresiones".
  2. Puede modificar los flujos de trabajo para usar un proceso en dos pasos que incluya pull_request_target, que no tiene estas limitaciones. Para obtener más información, consulte "Automatización de Dependabot con GitHub Actions".
  3. Puede proporcionar acceso a los flujos de trabajo que activa Dependabot a secretos y permitir que el término permissions aumente el alcance predeterminado de GITHUB_TOKEN. Para obtener más información, consulte "Proporcionar acceso a los flujos de trabajo que activa el Dependabot para los secretos y permisos incrementados" a continuación.

Proporcionar acceso a los flujos de trabajo que activa el Dependabot para los secretos y permisos incrementados

  1. Ingresa en el shell administrativo utilizando SSH. Para obtener más información, consulte "Acceso al shell administrativo (SSH)".
  2. Para eliminar estas limitaciones sobre los flujos de trabajo que activa el Dependabot en your GitHub Enterprise Server instance, utiliza el siguiente comando.
    $ ghe-config app.actions.disable-dependabot-enforcement true
  3. Aplique la configuración.
    $ ghe-config-apply
  4. Regresar a GitHub Enterprise Server.

Solución de problemas en las acciones empaquetadas en GitHub Actions

Si recibes el siguiente error al instalar GitHub Actions en GitHub Enterprise Server, puedes resolverlo instalando las acciones empaquetadas oficiales y los flujos de trabajo iniciales.

A part of the Actions setup had problems and needs an administrator to resolve.

Para instalar las acciones empaquetadas oficiales y flujos de trabajo iniciales dentro de una organización designada en GitHub Enterprise Server, realiza el siguiente procedimiento.

  1. Identifica una organización que almacenará las acciones empaquetadas oficiales y flujos de trabajo iniciales. Puedes crear una organización nueva o reutilizar una existente.

  2. Ingresa en el shell administrativo utilizando SSH. Para obtener más información, consulte "Acceso al shell administrativo (SSH)".

  3. Para designar la organización como la ubicación donde almacenar las acciones agrupadas, use el comando ghe-config y reemplace ORGANIZATION por el nombre de la organización.

    $ ghe-config app.actions.actions-org ORGANIZATION

    y:

    $ ghe-config app.actions.github-org ORGANIZATION
  4. Para agregar las acciones empaquetadas a tu organización, desactiva el SHA.

    $ ghe-config --unset 'app.actions.actions-repos-sha1sum'
  5. Aplique la configuración.

    $ ghe-config-apply

Una vez completados estos pasos, puede reanudar la configuración de GitHub Actions en "Administración de permisos de acceso para Acciones de GitHub en la empresa".