Migración de CircleCI a Acciones de GitHub

Acciones de GitHub y CircleCI comparten varias similitudes en la configuración, lo que hace que la migración a Acciones de GitHub relativamente sencilla.

En este artículo

Introducción

CircleCI y GitHub Actions ambos permiten crear flujos de trabajo que compilen, prueben, publiquen, publiquen e implementen código automáticamente. CircleCI y GitHub Actions comparten algunas similitudes 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 una o más tareas.
  • Los trabajos 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 Descripción de Acciones de GitHub.

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 está integrada en GitHub Actions.
  • Las acciones que se ejecutan en los contenedores de Docker son sensibles a problemas de permisos, ya que los contenedores tienen una asignación de usuarios diferente. Puede evitar muchos de estos problemas si no usa la instrucción USER en el Dockerfile. Para obtener más información sobre el sistema de archivos de Docker en ejecutores alojados en GitHub, consulte Referencia de ejecutores hospedados en GitHub.

Migrar flujos de trabajo y tareas

CircleCI define workflows en el archivo config.yml, que permite configurar más de un flujo de trabajo. GitHub requiere un archivo de flujo de trabajo por flujo de trabajo y, como consecuencia, no requiere que declare workflows. Tendrá que crear un archivo de flujo de trabajo para cada flujo de trabajo configurado en config.yml.

CircleCI y 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 equivalente GitHub Actionsneeds . Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub.

Migrar orbes a acciones

CircleCI y 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 tiene componentes reutilizables eficaces y flexibles denominados acciones, que se compilan con archivos javaScript o imágenes de Docker. Puede crear acciones escribiendo código personalizado que interactúe con el repositorio de cualquier manera que quiera, incluida la integración con GitHublas API de y 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 Reutilización de automatizaciones.

CircleCI puede reutilizar partes de los flujos de trabajo mediante anclas y alias de YAML. GitHub Actions admite anclajes y alias de YAML para la reutilización, y también proporciona matrices para ejecutar trabajos con distintas configuraciones. 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

CircleCI y GitHub Actions admiten 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 tienen USER configurado en circleci, lo que provoca conflictos de permisos con GitHub Actions.

Se recomienda alejarse de las imágenes precompiladas de CircleCI al migrar 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 Referencia de ejecutores hospedados en GitHub.

Para obtener más información sobre las herramientas y los paquetes disponibles en las imágenes del ejecutor hospedado de GitHub, consulte Ejecutores hospedados en GitHub.

Utilizar variables y secretos

CircleCI y GitHub Actions admiten la configuración de variables en el archivo de configuración y la creación de secretos mediante CircleCI o GitHub la interfaz de usuario.

Para más información, consulta Referencia de variables y Uso de secretos en Acciones de GitHub.

Almacenamiento en memoria caché

CircleCI y GitHub Actions proporcionan un método para almacenar en caché manualmente los archivos 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@v4
  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 de CircleCI (o DLC).

Datos persistentes entre jobs

CircleCI y GitHub Actions proporcionan mecanismos para conservar los datos entre trabajos.

A continuación se muestra un ejemplo en CircleCI y en la sintaxis de configuración 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@v5
  with:
    name: homework

Para más información, consulta Almacenamiento y uso compartido de datos con artefactos de 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 usa secciones explícitas: use container para el contenedor principal y enumere contenedores adicionales en services.

A continuación se muestra un ejemplo en CircleCI y en la sintaxis de configuración 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@v6
      - 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 Comunicación con contenedores de servicios de Docker.

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. A la derecha se muestra el GitHub Actions equivalente.

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@v6
      - name: Setup Ruby
        uses: eregon/use-ruby-action@ec02537da5712d66d4d50a0f33b7eb52773b5ed1
        with:
          ruby-version: ${{ matrix.ruby }}
      - name: Cache dependencies
        uses: actions/cache@v4
        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