Esta versión de GitHub Enterprise Server se discontinuó el 2024-07-09. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener rendimiento mejorado, seguridad mejorada y nuevas características, actualice a la versión más reciente de GitHub Enterprise Server. Para obtener ayuda con la actualización, póngase en contacto con el soporte técnico de GitHub Enterprise.

Solucionar problemas en las GitHub Actions de tu empresa

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

¿Quién puede utilizar esta característica?

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

En este artículo

Verificar la salud de las GitHub Actions

Puedes comprobar el estado de GitHub Actions en tu instancia de GitHub Enterprise Server con la utilidad de la línea de comandos ghe-actions-check. Para obtener más información, vea «Utilidades de la ea de comandos» y «Acceder 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, consulta "Configurar 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 establecer la variable de entorno como una variable de entorno del sistema o declararla en un archivo denominado .env en el directorio de aplicaciones del ejecutor autohospedado (es decir, el directorio en el que descargó y desempaquetó el software del ejecutor).

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 tu instancia de GitHub Enterprise Server:

  • Debe agregar .localhost, 127.0.0.1 y ::1 a la lista de exclusión de proxy HTTP (en ese orden).
  • Si la ubicación del almacenamiento externo no es enrutable, también debes agregar la dirección URL del almacenamiento externo a la lista de exclusión.

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

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, llegar hasta la interrupción del servicio y a la invalidación de las claves de seguridad de los usuarios. Si ha cambiado el nombre de host de la instancia y tiene problemas, póngase en contacto con Soporte técnico para GitHub Enterprise o Soporte prémium de GitHub.

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 tu instancia de GitHub Enterprise Server. 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, vea «Eliminar ejecutores autoalojados» y «Agrega ejecutores auto-hospedados».

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 tu instancia de GitHub Enterprise Server. 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, vea «Acceder al tablero del monitor».

Si la "Salud del sistema" para el uso total de CPU está cerca del 100 % o si ya no queda memoria libre, tu instancia de GitHub Enterprise Server se está ejecutando al total de su capacidad y necesita escalarse. Para obtener más información, vea «Aumentar el CPU o los recursos de 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, vea «Acceder 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 configurar las actualizaciones del Dependabot para tu instancia de GitHub Enterprise Server, puedes ver errores cuando los flujos de trabajo existentes los desencadenan 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, vea «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, vea «Automatizar al Dependabot con las 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 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, vea «Acceder al shell administrativo (SSH)».

  2. Para eliminar estas limitaciones sobre los flujos de trabajo que desencadena el Dependabot en tu instancia de GitHub Enterprise Server, 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, vea «Acceder 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, puedes reanudar la configuración de GitHub Actions en "Iniciar con GitHub Actions para GitHub Enterprise Server".