Skip to main content
Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Esta versión de GitHub Enterprise se discontinuó el 2022-06-03. No se realizarán lanzamientos de patch, ni siquiera para problemas de seguridad críticos. Para obtener un mejor desempeño, más seguridad y nuevas características, actualiza a la última versión de GitHub Enterprise. Para obtener ayuda con la actualización, contacta al soporte de GitHub Enterprise.

Soporte de Dockerfile para GitHub Actions

Cuando creas un "Dockerfile" para una acción de un contenedor de Docker, debes estar consciente de cómo interactúan algunas instrucciones de Docker con GitHub Actions y con el archivo de metadatos de la acción.

Nota: Los ejecutores hospedados en GitHub no son compatibles con GitHub Enterprise Server actualmente. Puedes encontrar más información sobre el soporte que se tiene planeado en el futuro en el Itinerario público de GitHub.

Acerca de las instrucciones de Dockerfile

Un Dockerfile contiene instrucciones y argumentos que definen el contenido y comportamiento inicial de un contenedor de Docker. Para obtener más información acerca de las instrucciones compatibles con Docker, consulta la sección "Dockerfile reference" en la documentación de Docker.

Instrucciones e invalidaciones de Dockerfile

Algunas instrucciones de Docker interactúan con GitHub Actions, y un archivo de metadatos de la acción puede invalidar algunas instrucciones de Docker. Asegúrate de que estás familiarizado con la manera en que tu Dockerfile interactúa con GitHub Actions para prevenir cualquier comportamiento inesperado.

USER

Las acciones de Docker deben ejecutarse mediante el usuario predeterminado de Docker (root). No utilices la instrucción USER en tu Dockerfile, ya que no podrás acceder a GITHUB_WORKSPACE. Para obtener más información, consulta la sección "Utilizar variables del ambiente" y USER reference en la documentación de Docker.

FROM

La primera instrucción en el Dockerfile debe ser FROM, la cual selecciona una imagen base de Docker. Para obtener más información, consulta la sección "FROM reference en la documentación de Docker.

Estas son algunas de las mejores prácticas para configurar el argumento FROM:

  • Se recomienda utilizar imágenes oficiales de Docker. Por ejemplo, python o ruby.
  • Utiliza una etiqueta de versión si es que existe, preferentemente con una versión mayor. Por ejemplo, utiliza node:10 en vez de node:latest.
  • Se recomienda utilizar imágenes de Docker que se basen en el sistema operativo Debian.

WORKDIR

GitHub Enterprise Server configura la ruta del directorio de trabajo en la variable de ambiente GITHUB_WORKSPACE. No se recomienda utilizar la instrucción WORKDIR en tu Dockerfile. Antes de que se ejecute la acción, GitHub Enterprise Server montará el directorio GITHUB_WORKSPACEsobre cualquiera que fuera la ubicación en la imagen de Docker y configurará a GITHUB_WORKSPACE como el directorio de trabajo. Para obtener más información, consulta la sección "Utilizar variables de ambiente" y WORKDIR reference en la documentación de Docker.

ENTRYPOINT

Si defines el entrypoint en un archivo de metadatos de una acción, este invalidará el ENTRYPOINT definido en el Dockerfile. Para obtener más información, consulta la sección "Sintaxis de metadatos para GitHub Actions".

La instrucción ENTRYPOINT de Docker tiene una forma de shell y una de exec. La documentación de ENTRYPOINT de Docker recomienda utilizar la forma de exec de la instrucción ENTRYPOINT. Para obtener más información acerca de las formas exec y shell, consulta la sección ENTRYPOINT reference en la documentación de Docker.

No deberías utilizar WORKDIR para especificar el punto de entrada en tu Dockerfile. En vez de esto, deberías utilizar una ruta absoluta. Para obtener más información, consulta la sección WORKDIR.

Si configuras tu contenedor para que utilice la forma exec de la instrucción ENTRYPOINT, entonces el args configurado en el archivo de metadatos de la acción no se ejecutará en un shell de comandos. Si el args de la accion contiene una variable de ambiente, ésta no se sustituirá. Por ejemplo, utilizar el siguiente formato exec no imprimirá los valores almacenados en $GITHUB_SHA, si no que imprimirá "$GITHUB_SHA".

ENTRYPOINT ["echo $GITHUB_SHA"]

Si quieres la sustitución de variables, entonces puedes utilizar la forma shell o ejecutar el shell directamente. Por ejemplo, al utilizar el siguiente formato exec puedes ejecutar un shell para imprimir el valor almacenado en la variable de ambiente GITHUB_SHA.

ENTRYPOINT ["sh", "-c", "echo $GITHUB_SHA"]

Para proporcionar el args que se definió en el archivo de metadatos de la acción en un contenedor de Docker que utiliza la forma exec en el ENTRYPOINT, recomendamos crear un script de shell llamado entrypoint.sh al que puedas llamar desde la instrucción ENTRYPOINT:

Dockerfile de ejemplo

# Container image that runs your code
FROM debian:9.5-slim

# Copies your code file from your action repository to the filesystem path `/` of the container
COPY entrypoint.sh /entrypoint.sh

# Executes `entrypoint.sh` when the Docker container starts up
ENTRYPOINT ["/entrypoint.sh"]

Archivo entrypoint.sh de ejemplo

Al utilizar el Dockerfile de ejemplo que se muestra anteriormente, GitHub Enterprise Server enviará el args configurado en el archivo de metadatos de la acción como un argumento de entrypoint.sh. Agrega el #!/bin/sh shebang hasta arriba del archivo entrypoint.sh para utilizar explicitamente el shell compilante POSIX del sistema.

#!/bin/sh

# `$*` expands the `args` supplied in an `array` individually
# or splits `args` in a string separated by whitespace.
sh -c "echo $*"

Tu código debe ser ejecutable. Asegúrate que el archivo entrypoint.sh tiene permisos de execute antes de utilizarlo en un flujo de trabajo. Puedes modificar los permisos de tu terminal si utilizas este comando:

chmod +x entrypoint.sh

Cuando un script de shell de ENTRYPOINT no es ejecutable, recibirás un error similar al siguiente:

Error response from daemon: OCI runtime create failed: container_linux.go:348: starting container process caused "exec: \"/entrypoint.sh\": permission denied": unknown

CMD

Si defines el args en el archivo de metadatos de la acción, args invalidará la instrucción CMD especificada en el Dockerfile. Para obtener más información, consulta la sección "Sintaxis de metadatos para GitHub Actions".

Si utilizas CMD en tu Dockerfile, sigue estos lineamientos:

  1. Los documentos requerían argumentos en el README de las acciones y las omiten desde la instrucción CMD.
  2. Usa los valores predeterminados que permiten usar la acción sin especificar ningún args.
  3. Si la acción expone una marca de --help, o algo similar, utilízala para hacer tu propia documentación de la acción.

Capacidades de Linux compatibles

GitHub Actions es compatible con las capacidades predeterminadas de Linux que acepta Docker. Estas capacidades no se pueden añadir ni eliminar. Para obtener más información acerca de las capacidades predeterminadas de Linux con las cuales es compatible Docker, consulta "Runtime priovilege and Linux capabilities" en la documentación de Docker. Para conocer más acerca de las capacidades de Linux, consulta "Overview of Linux capabilities en las páginas man de Linux.