👋 We've unified all of GitHub's product documentation in one place! Check out the content for REST API, GraphQL API, and Developers. Learn more on the GitHub blog.


Frecuentemente publicamos actualizaciones de nuestra documentación. Es posible que la traducción de esta página esté en curso. Para conocer la información más actual, visita la documentación en inglés. Si existe un problema con las traducciones en esta página, por favor infórmanos.

Migrar de CircleCI a GitHub Actions

GitHub Actions y CircleCi comparten varias configuraciones similares, lo cual hace que migrar a GitHub Actions sea relativamente fácil.

En este artículo

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, consulta la sección "Ambientes virtuales para los ejecutores hospedados en GitHub".

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 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 "Sintaxis del flujo de trabajo paraGitHub 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 escribiendo un código personalizado que interactúe con tu repositorio de la manera que desees, incluida la integración con las API de GitHub 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 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 matrices de compilación, consulta la sección "Configurar 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. 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".

Para obtener más información acerca de las herramientas y paquetes disponibles en los ambientes virtuales hospedados en GitHub, consulta la sección "Software instalado en 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.

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.

A continuación encontrarás un ejemplo de la sintaxis para cada sistema.

CircleCI Acciones de GitHub
- restore_cache:
    keys:
      - v1-npm-deps-{{ checksum "package-lock.json" }}
      - v1-npm-deps-
- name: Cache node modules
  uses: actions/cache@v2
  with:
    path: ~/.npm
    key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
    restore-keys: v1-npm-deps-

Para obtener más información, consulta "Almacenar en caché las dependencias 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 Acciones de GitHub
- persist_to_workspace:
    root: workspace
    paths:
      - math-homework.txt

...

- attach_workspace:
    at: /tmp/workspace
- name: Upload math result for job 1
  uses: actions/upload-artifact@v1
  with:
    name: homework
    path: math-homework.txt

...

- name: Download math result for job 1
  uses: actions/download-artifact@v1
  with:
    name: homework

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 encontrarás un ejemplo en la sintaxis de configuración tanto de CircleCi como de GitHub Actions.

CircleCI Acciones de GitHub
---
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
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://help.github.com/en/actions/reference/virtual-environments-for-github-hosted-runners#docker-container-filesystem
    - name: Setup file system permissions
      run: sudo chmod -R 777 $GITHUB_WORKSPACE /github /__w/_temp
    - uses: actions/checkout@v2
    - 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 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
---
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
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@v2
    - name: Setup Ruby
      uses: eregon/use-ruby-action@master
      with:
        ruby-version: ${{ matrix.ruby }}
    - name: Cache dependencies
      uses: actions/cache@v2
      with:
        path: vendor/bundle
        key: administrate-${{ matrix.image }}-${{ hashFiles('Gemfile.lock') }}
    - name: Install postgres headers
      run: 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

Pregunta a una persona

¿No puedes encontrar lo que estás buscando?

Contáctanos