Nota: GitHub Actions estuvo disponible para GitHub Enterprise Server 2.22 como un beta limitado. El beta terminó. GitHub Actions está ahora disponible habitualmente en GitHub Enterprise Server 3.0 o superior. Para obtener más información, consulta la sección de notas de lanzamiento para GitHub Enterprise Server 3.0.
- Para obtener más información acerca de cómo mejorar a GitHub Enterprise Server 3.0 o superior, consulta la sección "Mejorar a GitHub Enterprise Server".
- Para obtener más información acerca de configurar las GitHub Actions después de tu mejora, consulta la documentación de GitHub Enterprise Server 3.0.
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
oruby
. - Utiliza una etiqueta de versión si es que existe, preferentemente con una versión mayor. Por ejemplo, utiliza
node:10
en vez denode: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_WORKSPACE
sobre 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.
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:
- Los documentos requerían argumentos en el README de las acciones y las omiten desde la instrucción
CMD
. - Usa los valores predeterminados que permiten usar la acción sin especificar ningún
args
. - 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.