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.
Introducción
Tanto la IC/EC de GitLab como las GitHub Actions te permiten crear flujos de trabajo que crean, prueban, publican, lanzan y despliegan código automáticamente. La IC/EC de GitLab y las GitHub Actions comparten algunas similitudes en la configuración de los flujos de trabajo:
- Los archivos de configuración de flujo de trabajo están escritas en YAML y se almacenan en el repositorio del código.
- Los flujos de trabajo incluyen uno o más jobs.
- Los jobs incluyen uno o más pasos o comandos individuales.
- Los jobs pueden ejecutarse ya sea en máquinas administradas o auto-hospedadas.
Hay unas cuantas diferencias, y esta guía te mostrará las diferencias importantes para que puedas migrar tu flujo de trabajo a GitHub Actions.
Jobs
Los jobs en la IC/EC de GitLab son muy similares a aquellos en GitHub Actions. En ambos sistemas, los jobs tienen las siguientes características:
- Los jobs contienen una serie de pasos o scripts que se ejecutan secuencialmente.
- Los jobs pueden ejecutarse en máquinas o contenedores separados.
- Los jobs se ejecutan en paralelo predeterminadamente, pero pueden configurarse para ejecutarse en secuencia.
Puedes ejecutar un script o un comando de shell en un job. En la IC/EC de GitLab, los pasos de los scripts se especifican utilizando la clave script
. En GitHub Actions, todos los scripts se especifican utilizando la clave run
.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Ejecutores
Los ejecutores son máquinas en donde se ejecutan los jobs. Tanto la IC/EC de GitLab como las GitHub Actions ofrecen variantes administradas y auto-hospedadas de los ejecutores. En la IC/EC de GitLab, se utilizan las tags
para ejecutar jobs en plataformas diferentes, mientras que en las GitHub Actions todo se realiza con la clave runs-on
.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para las GitHub Actions".
Imágenes de Docker
Tanto la IC/EC de GitLab como las GitHub Actions son compatibles con la ejecución de jobs en una imagen de Docker. En la IC/EC de GitLab, las imágenes de Docker se definen con una clave de image
, mientras que en las GitHub Actions se hace con la clave container
.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para GitHub Actions".
Sintaxis de condiciones y expresiones
La IC/EC de GitLab utiliza rules
para determinar si un job se ejecutará para una condición específica. Las GitHub Actions utilizan la palabra clave if
para prevenir que un job se ejecute a menos de que se cumpla con una condición.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Expresiones".
Dependencias entre los Jobs
Tanto la IC/EC de GitLab como las GitHub Actions te permiten configurar dependencias para un job. En ambos sistemas, los jobs se ejecutan en paralelo predeterminadamente, pero las dependencias de éstos en las GitHub Actions se pueden especificar explícitamente con la clave needs
. La IC/EC de GitLab también tiene un concepto de stages
, en donde los jobs de una etapa se ejecutan simultáneamente, pero la siguiente etapa comenzaría cuando todos los jobs de la etapa previa se hayan completado. Puedes crecrear este escenario en las GitHub Actions con la palabra clave needs
.
Puedes encontrar un ejemplo de la sintaxis para cada sistema. Los flujos de trabajo comienzan con dos jobs que se llaman build_a
y build_b
ejecutándose en paralelo y, cuando estos jobs se completan, se ejecutará otro job llamado test_ab
. Finalmente, cuando se completa el test_ab
, se ejecutará el job deploy_ab
.
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para GitHub Actions".
Programar flujos de trabajo
Tanto la IC/EC de GitLab como las GitHub Actions te permiten ejecutar flujos de trabajo en un intervalo específico. En la IC/EC de GitLab, las programaciones de mapa se configuran con la IU, mientras que en las GitHub Actions puedes activar un flujo de trabajo en un intervalo programado con la clave "on".
Para obtener más información, consulta la sección "Eventos que activan los flujos de trabajo".
Variables y secretos
La IC/EC de GitLab y las GitHub Actions son compatibles con la configuración de variables de ambiente en el mapa o en el archivo de configuración de flujo de trabajo, y con la creación de secretos utilizando la IU de GitLab o de GitHub Enterprise Server.
Para obtener más información, consulta las secciones "Variables de ambiente" y "Secretos cifrados".
Almacenamiento en caché
La IC/EC de GitLab y las GitHub Actions proporcionan un método en el archivo de configuración para guardar los archivos de flujo de trabajo manualmente en el caché.
GitHub Actions caching is only available for repositories hosted on GitHub.com or GitHub Enterprise Server 3.5 and later. Para obtener más información, consulta la sección "Almacenar las dependencias en caché para agilizar los flujos de trabajo."
Artefactos
Tanto la IC/EC de GitLab como las GitHub Actions pueden cargar como artefactos los archivos y directorios que creen los jobs. En las GitHub Actions, los artefactos pueden utilizarse para persistir los datos a través de varios jobs.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Almacenar los datos de los flujos de trabajo como artefactos".
Bases de datos y contenedores de servicios
Ambos sistemas te permiten incluir contenedores adicionales para bases de datos, almacenamiento en caché, u otras dependencias.
En la IC/EC de GitLab, un contenedor para el job se especifica con la clave image
key, mientras que las GitHub Actions utilizan la clave container
. En ambos sistemas se especifican contenedores de servicio adicionales con la clave services
.
Puedes encontrar un ejemplo de la sintaxis para cada sistema:
IC/EC de GitLab | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Acerca de los contenedores de servicio".