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 más información, consulta Entender las 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. Puede evitar muchos de estos problemas si no usa la instrucción
USER
en el Dockerfile. Para más información, sobre el sistema de archivos de Docker en ejecutores hospedados en GitHub, consulta Utilizar los ejecutores hospedados en GitHub.
Migrar flujos de trabajo y jobs
CircleCI define workflows
en el archivo config.yml, que permite configurar más de un flujo de trabajo. GitHub necesita un archivo de flujo de trabajo por flujo de trabajo y, por tanto, no necesita que se declare workflows
. Tendrá que crear un archivo de flujo de trabajo para cada flujo de trabajo configurado en config.yml.
Tanto CircleCI como GitHub Actions configuran jobs
en el archivo de configuración mediante una sintaxis similar. Si configura dependencias entre trabajos mediante requires
en el flujo de trabajo de CircleCI, puede usar la sintaxis needs
equivalente de GitHub Actions. Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub.
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 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 problemas urgentes o implementar código listo para producción. Para más información, consulta Uso compartido de automatizaciones.
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. Para obtener más información sobre las matrices, consulta Ejecución de variaciones de trabajos en un flujo de trabajo.
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. En estas imágenes, USER
se establece en circleci
, lo que hace que los permisos entren en conflicto 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 más información sobre el sistema de archivos de Docker, consulta Utilizar los ejecutores hospedados en GitHub.
Para más información sobre las herramientas y los paquetes disponibles en imágenes de ejecutores hospedados en GitHub, consulta Utilizar los ejecutores hospedados en GitHub.
Utilizar variables y secretos
CircleCI y GitHub Actions son compatibles con la configuración de variables en el archivo de configuración y con la creación de secretos usando la IU de CircleCI o de GitHub.
Para más información, consulta Almacenamiento de información en variables y Uso de secretos en Acciones de GitHub.
Almacenamiento en memoria caché
CircleCI y GitHub Actions proporcionan un método para almacenar archivos en cahcé manualmente en el archivo de configuración.
A continuación encontrarás un ejemplo de la sintaxis para cada sistema.
Sintaxis de CircleCI para el almacenamiento en caché
- restore_cache:
keys:
- v1-npm-deps-{{ checksum "package-lock.json" }}
- v1-npm-deps-
Sintaxis de Acciones de GitHub para el almacenamiento en caché
- name: Cache node modules
uses: actions/cache@v3
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
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 encontrarás un ejemplo en la sintaxis de configuración tanto de CircleCi como de GitHub Actions.
Sintaxis de CircleCI para conservar datos entre trabajos
- persist_to_workspace:
root: workspace
paths:
- math-homework.txt
...
- attach_workspace:
at: /tmp/workspace
Sintaxis de Acciones de GitHub para conservar datos entre trabajos
- name: Upload math result for job 1
uses: actions/upload-artifact@v4
with:
name: homework
path: math-homework.txt
...
- name: Download math result for job 1
uses: actions/download-artifact@v4
with:
name: homework
Para más información, consulta Almacenamiento y uso compartido de datos desde un flujo de trabajo.
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 enumerada en config.yaml es la imagen primaria que se usa para ejecutar comandos. GitHub Actions utiliza secciones explícitas: use container
para el contenedor principal y enumere contenedores adicionales en services
.
A continuación encontrarás un ejemplo en la sintaxis de configuración tanto de CircleCi como de GitHub Actions.
Sintaxis de CircleCI para usar bases de datos y contenedores de servicios
---
version: 2.1
jobs:
ruby-26:
docker:
- image: circleci/ruby:2.6.3-node-browsers-legacy
environment:
PGHOST: localhost
PGUSER: administrate
RAILS_ENV: test
- image: postgres:10.1-alpine
environment:
POSTGRES_USER: administrate
POSTGRES_DB: ruby26
POSTGRES_PASSWORD: ""
working_directory: ~/administrate
steps:
- checkout
# Bundle install dependencies
- run: bundle install --path vendor/bundle
# Wait for DB
- run: dockerize -wait tcp://localhost:5432 -timeout 1m
# Setup the environment
- run: cp .sample.env .env
# Setup the database
- run: bundle exec rake db:setup
# Run the tests
- run: bundle exec rake
workflows:
version: 2
build:
jobs:
- ruby-26
...
- attach_workspace:
at: /tmp/workspace
Sintaxis de Acciones de GitHub para usar bases de datos y contenedores de servicios
name: Containers
on: [push]
jobs:
build:
runs-on: ubuntu-latest
container: circleci/ruby:2.6.3-node-browsers-legacy
env:
PGHOST: postgres
PGUSER: administrate
RAILS_ENV: test
services:
postgres:
image: postgres:10.1-alpine
env:
POSTGRES_USER: administrate
POSTGRES_DB: ruby25
POSTGRES_PASSWORD: ""
ports:
- 5432:5432
# Add a health check
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
# This Docker file changes sets USER to circleci instead of using the default user, so we need to update file permissions for this image to work on GH Actions.
# See https://docs.github.com/actions/using-github-hosted-runners/about-github-hosted-runners#docker-container-filesystem
- name: Setup file system permissions
run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
- uses: actions/checkout@v4
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
Para más información, consulta Acerca de los contenedores de servicios.
Ejemplo completo
A continuación encontrarás un ejemplo real. A la izquierda se muestra el archivo config.yml real de CircleCI para el repositorio thoughtbot/administrator. La derecha muestra el equivalente en GitHub Actions.
Ejemplo completo de CircleCI
---
version: 2.1
commands:
shared_steps:
steps:
- checkout
# Restore Cached Dependencies
- restore_cache:
name: Restore bundle cache
key: administrate-{{ checksum "Gemfile.lock" }}
# Bundle install dependencies
- run: bundle install --path vendor/bundle
# Cache Dependencies
- save_cache:
name: Store bundle cache
key: administrate-{{ checksum "Gemfile.lock" }}
paths:
- vendor/bundle
# Wait for DB
- run: dockerize -wait tcp://localhost:5432 -timeout 1m
# Setup the environment
- run: cp .sample.env .env
# Setup the database
- run: bundle exec rake db:setup
# Run the tests
- run: bundle exec rake
default_job: &default_job
working_directory: ~/administrate
steps:
- shared_steps
# Run the tests against multiple versions of Rails
- run: bundle exec appraisal install
- run: bundle exec appraisal rake
jobs:
ruby-25:
<<: *default_job
docker:
- image: circleci/ruby:2.5.0-node-browsers
environment:
PGHOST: localhost
PGUSER: administrate
RAILS_ENV: test
- image: postgres:10.1-alpine
environment:
POSTGRES_USER: administrate
POSTGRES_DB: ruby25
POSTGRES_PASSWORD: ""
ruby-26:
<<: *default_job
docker:
- image: circleci/ruby:2.6.3-node-browsers-legacy
environment:
PGHOST: localhost
PGUSER: administrate
RAILS_ENV: test
- image: postgres:10.1-alpine
environment:
POSTGRES_USER: administrate
POSTGRES_DB: ruby26
POSTGRES_PASSWORD: ""
workflows:
version: 2
multiple-rubies:
jobs:
- ruby-26
- ruby-25
Ejemplo completo de Acciones de GitHub
# Este flujo de trabajo usa acciones que no GitHub no certifica.
# Estas las proporcionan entidades terceras y las gobiernan
# condiciones de servicio, políticas de privacidad y documentación de soporte
# en línea.
# GitHub recomienda anclar acciones a un SHA de confirmación.
# Para obtener una versión más reciente, debes actualizar el SHA.
# También puedes hacer referencia a una etiqueta o rama, pero la acción puede cambiar sin ninguna advertencia.
name: Containers
on: [push]
jobs:
build:
strategy:
matrix:
ruby: ['2.5', '2.6.3']
runs-on: ubuntu-latest
env:
PGHOST: localhost
PGUSER: administrate
RAILS_ENV: test
services:
postgres:
image: postgres:10.1-alpine
env:
POSTGRES_USER: administrate
POSTGRES_DB: ruby25
POSTGRES_PASSWORD: ""
ports:
- 5432:5432
# Add a health check
options: --health-cmd pg_isready --health-interval 10s --health-timeout 5s --health-retries 5
steps:
- uses: actions/checkout@v4
- name: Setup Ruby
uses: eregon/use-ruby-action@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
with:
ruby-version: ${{ matrix.ruby }}
- name: Cache dependencies
uses: actions/cache@v3
with:
path: vendor/bundle
key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
- name: Install postgres headers
run: |
sudo apt-get update
sudo apt-get install libpq-dev
- name: Install dependencies
run: bundle install --path vendor/bundle
- name: Setup environment configuration
run: cp .sample.env .env
- name: Setup database
run: bundle exec rake db:setup
- name: Run tests
run: bundle exec rake
- name: Install appraisal
run: bundle exec appraisal install
- name: Run appraisal
run: bundle exec appraisal rake