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.
Introducción
Tanto CircleCi como GitHub Actions te permiten crear flujos de trabajo que compilan, prueban, publican, lanzan y despliegan código automáticamente. CircleCI y GitHub Actions comparten algunas similaridades en la configuración del flujo de trabajo:
- Los archivos de configuración de flujo de trabajo están escritos en YAML y se almacenan en el repositorio.
- Los flujos de trabajo incluyen uno o más jobs.
- Los jobs incluyen uno o más pasos o comandos individuales.
- Los pasos o tareas pueden reutilizarse y compartirse con la comunidad.
Para obtener más información, consulta la sección "Conceptos esenciales para GitHub Actions".
Diferencias clave
Cuando migres desde CircleCI, considera las siguientes diferencias:
- El paralelismo automático de pruebas de CircleCI agrupa las pruebas automáticamente de acuerdo con las reglas que el usuario haya especificado o el historial de información de tiempos. Esta funcionalidad no se incluye en GitHub Actions.
- Las acciones que se ejecutan en los contenedores de Docker distinguen entre problemas de permisos, ya que los contenedores tienen un mapeo de usuarios diferente. Puedes evitar muchos de estos problemas si no utilizas la instrucción
USER
en tu Dockerfile. Para obtener más información acerca del sistema de archivos de Docker en los ejecutores hospedados en GitHub Enterprise Server, consulta la sección "Ambientes virtuales para los ejecutores hospedados en GitHub Enterprise Server".
Migrar flujos de trabajo y jobs
CircleCi define los workflows
en el archivo config.yml, lo cual te permite configurar más de un flujo de trabajo. GitHub Enterprise Server requiere tratar los flujos de trabajo uno por uno y, como consecuencia, no necesita que declares los workflows
. Necesitarás crear un nuevo archivo de flujo de trabajo para cada flujo que se haya configurado en config.yml.
Tanto CircleCI como GitHub Actions configuran jobs
en el archivo de configuración utilizando una sintaxis similar. Si configurars cualquier dependencia entre jobs utilizando requires
en tu flujo de trabajo de CircleCI, puedes utilizar la sintaxis de GitHub Actions equivalente "needs
". Para obtener más información, consulta la sección "Sintaxis de flujo de trabajo para GitHub Actions".
Mirgrar orbes a acciones
Tanto CircleCI como GitHub Actions proporcionan un mecanismo para reutilizar y compartir tareas en un flujo de trabajo. CircleCi utiliza un concepto llamado orbes (orbs), escrito en YAML, que proporciona tareas que las personas pueden reutilizar en un flujo de trabajo. GitHub Actions cuenta con componentes reutilizables poderosos y flexibles llamados acciones (actions), los cuales compilas ya sea con archivos de JavaScript o con imagenes de Docker. Puedes crear acciones si escribes tu código personalizado para que interactúe con tu repositorio en la forma que prefieras, lo cual incluye la integración con las API de GitHub Enterprise Server y con cualquier API de terceros disponible públicamente. Por ejemplo, una acción puede publicar módulos npm, enviar alertas por SMS cuando se crean propuestas urgentes o implementar un código listo para producción. Para obtener más información, consulta la sección "Crear acciones".
Circle CI puede reutilizar partes de los flujos de trabajo con anclas y alias. GitHub Actions es compatible con las necesidades de reutilización más comunes utilizando matrices de compilación. Para obtener más información acerca de las matrices de compilación, consulta la sección "Administrar flujos de trabajo complejos".
Utilizar imágenes de Docker
Tanto CircleCi como GitHub Actions son compatibles con la ejecución de pasos dentro de una imagen de Docker.
CircleCi proporciona un conjunto de imágenes pre-compiladas con dependencias comunes. Estas imágenes cuentan con el USER
configurado como circleci
, lo cual ocasiona que los permisos choquen con GitHub Actions.
Recomendamos que te retires de las imágenes pre-compiladas de CircleCi cuando migres a GitHub Actions. En muchos casos, puedes utilizar acciones para instalar dependencias adicionales que necesites.
Para obtener más información acerca del sistema de archivos de Docker, consulta la sección "Ambientes virtuales para los ejecutores hospedados en GitHub Enterprise Server". Para obtener más información sobre las herramientas y paquetes disponibles en
los ambientes hospedados en GitHub, consulta la sección "Especificaciones para los ejecutores hospedados en GitHub".
Utilizar variables y secretos
CircleCi y GitHub Actions son compatibles con la configuración de variables de ambiente en el archivo de configuración y con la creación de secretos utilizando la IU de CircleCI o de GitHub Enterprise Server.
Para obtener más información, consulta la sección "Utilizar variables de ambiente" y "Crear y utilizar secretos cifrados".
Almacenamiento en caché
CircleCI y GitHub Actions proporcionan un método para almacenar archivos en cahcé manualmente en el archivo de configuración.
Puedes encontrar un ejemplo de la sintaxis para cada sistema.
CircleCI | GitHub Actions |
---|---|
|
|
El almacenamiento en caché de las GitHub Actions solo se aplica a los repositorios que se hospedan en GitHub.com. Para obtener más información, consulta la sección "Almacenar las dependencias en caché para agilizar los flujos de trabajo".
GitHub Actions no tiene un equivalente al Almacenamiento en Caché por Capas de Docker (o DLC, por sus siglas en inglés) que tiene CircleCI.
Datos persistentes entre jobs
Tanto CircleCi como GitHub Actions proporcionan mecanismos para persistir datos entre jobs.
A continuación puedes encontrar un ejemplo de la sintaxis de configuración de CircleCi y de GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta "Conservar datos de flujo de trabajo mediante artefactos."
Usar bases de datos y contenedores de servicio
Ambos sistemas te permiten incluir contenedores adicionales para bases de datos, almacenamiento en caché, u otras dependencias.
En CircleCi, la primera imagen listada en el config.yaml es la imagen primaria que se utiliza para ejecutar comandos. GitHub Actions utiliza secciones explícitas: utiliza container
para el contenedor primario, y lista contenedores adicionales en services
.
A continuación puedes encontrar un ejemplo de la sintaxis de configuración de CircleCi y de GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|
Para obtener más información, consulta la sección "Acerca de los contenedores de servicio".
Ejemplo Completo
A continuación encontrarás un ejemplo real. A la izquierda puedes ver el config.yml real de CircleCi para el repositorio thoughtbot/administrator. La derecha muestra el equivalente en GitHub Actions.
CircleCI | GitHub Actions |
---|---|
|
|