Migrarse desde la IC/EC de GitLab a GitHub Actions

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.

Trabajos

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 CI/CD de GitLab, los pasos de script se especifican con la clave script. En GitHub Actions, todos los scripts se especifican con la clave run.

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

Sintaxis de CI/CD de GitLab para trabajos

job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"

Sintaxis de GitHub Actions para trabajos

jobs:
  job1:
    steps:
      - uses: actions/checkout@v4
      - run: echo "Run your script here"

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 CI/CD de GitLab, tags se usan para ejecutar trabajos en distintas plataformas, mientras que en GitHub Actions se realiza con la clave runs-on.

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

Sintaxis de CI/CD de GitLab para ejecutores

windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job:
  tags:
    - linux
  script:
    - echo "Hello, $USER!"

Sintaxis de GitHub Actions para ejecutores

windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

linux_job:
  runs-on: ubuntu-latest
  steps:
    - run: echo "Hello, $USER!"

Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub.

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 CI/CD de GitLab, las imágenes de Docker se definen con una clave image, mientras que en GitHub Actions se realiza con la clave container.

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

Sintaxis de CI/CD de GitLab para imágenes de Docker

my_job:
  image: node:20-bookworm-slim

Sintaxis de GitHub Actions para imágenes de Docker

jobs:
  my_job:
    container: node:20-bookworm-slim

Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub.

Sintaxis de condiciones y expresiones

En CI/CD de GitLab se usa rules para determinar si un trabajo se ejecutará para una condición específica. Las GitHub Actions utilizan la palabra clave if para prevenir que un trabajo se ejecute a menos que se cumpla una condición.

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

Sintaxis de CI/CD de GitLab para condiciones y expresiones

deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'

Sintaxis de GitHub Actions para condiciones y expresiones

jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

Para más información, consulta Evaluación de expresiones en flujos de trabajo y acciones.

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 trabajos se ejecutan en paralelo de manera predeterminada, pero las dependencias de éstos en las GitHub Actions se pueden especificar explícitamente con la clave needs. La CI/CD de GitLab también tiene un concepto de stages, en donde los trabajos de una etapa se ejecutan simultáneamente, pero la siguiente etapa comenzará cuando todos los trabajos de la etapa anterior se hayan completado. Puedes recrear este escenario en GitHub Actions con la clave needs.

A continuación encontrarás un ejemplo de la sintaxis para cada sistema. Los flujos de trabajo comienzan con dos trabajos denominados build_a y build_b ejecutándose en paralelo, y cuando se completan esos trabajos, se ejecuta otro trabajo denominado test_ab. Por último, cuando test_ab se complete, se ejecutará el trabajo deploy_ab.

Sintaxis de CI/CD de GitLab para dependencias entre trabajos

stages:
  - build
  - test
  - deploy

build_a:
  stage: build
  script:
    - echo "This job will run first."

build_b:
  stage: build
  script:
    - echo "This job will run first, in parallel with build_a."

test_ab:
  stage: test
  script:
    - echo "This job will run after build_a and build_b have finished."

deploy_ab:
  stage: deploy
  script:
    - echo "This job will run after test_ab is complete"

Sintaxis de GitHub Actions para dependencias entre trabajos

jobs:
  build_a:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."

  build_b:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first, in parallel with build_a"

  test_ab:
    runs-on: ubuntu-latest
    needs: [build_a,build_b]
    steps:
      - run: echo "This job will run after build_a and build_b have finished"

  deploy_ab:
    runs-on: ubuntu-latest
    needs: [test_ab]
    steps:
      - run: echo "This job will run after test_ab is complete"

Para más información, consulta Sintaxis del flujo de trabajo para Acciones de GitHub.

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 más información, consulta Eventos que desencadenan flujos de trabajo.

Variables y secretos

La IC/EC de GitLab y las GitHub Actions son compatibles con la configuración de variables en el mapa o en el archivo de configuración de flujo de trabajo, y con la creación de secretos usando la IU de GitLab o de GitHub Enterprise Server.

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

Almacenamiento en memoria 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é.

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

Sintaxis de CI/CD de GitLab para almacenamiento en caché

image: node:latest

cache:
  key: $CI_COMMIT_REF_SLUG
  paths:
    - .npm/

before_script:
  - npm ci --cache .npm --prefer-offline

test_async:
  script:
    - node ./specs/start.js ./specs/async.spec.js

Sintaxis de GitHub Actions para almacenamiento en caché

jobs:
  test_async:
    runs-on: ubuntu-latest
    steps:
    - name: Cache node modules
      uses: actions/cache@v3
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

Artifacts

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.

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

Sintaxis de CI/CD de GitLab para artefactos

script:
artifacts:
  paths:
    - math-homework.txt

Sintaxis de GitHub Actions para artefactos

- name: Upload math result for job 1
  uses: actions/upload-artifact@v3
  with:
    name: homework
    path: math-homework.txt

Para más información, consulta Almacenamiento y uso compartido de datos desde un flujo de trabajo.

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 CI/CD de GitLab, se especifica un contenedor para el trabajo con la clave image, mientras que en GitHub Actions se usa la clave container. En ambos sistemas, se especifican contenedores de servicio adicionales con la clave services.

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

Sintaxis de CI/CD de GitLab para bases de datos y contenedores de servicios

container-job:
  variables:
    POSTGRES_PASSWORD: postgres
    # The hostname used to communicate with the
    # PostgreSQL service container
    POSTGRES_HOST: postgres
    # The default PostgreSQL port
    POSTGRES_PORT: 5432
  image: node:20-bookworm-slim
  services:
    - postgres
  script:
    # Performs a clean installation of all dependencies
    # in the `package.json` file
    - npm ci
    # Runs a script that creates a PostgreSQL client,
    # populates the client with data, and retrieves data
    - node client.js
  tags:
    - docker

Sintaxis de GitHub Actions para bases de datos y contenedores de servicios

jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:20-bookworm-slim

    services:
      postgres:
        image: postgres
        env:
          POSTGRES_PASSWORD: postgres

    steps:
      - name: Check out repository code
        uses: actions/checkout@v4

      # Performs a clean installation of all dependencies
      # in the `package.json` file
      - name: Install dependencies
        run: npm ci

      - name: Connect to PostgreSQL
        # Runs a script that creates a PostgreSQL client,
        # populates the client with data, and retrieves data
        run: node client.js
        env:
          # The hostname used to communicate with the
          # PostgreSQL service container
          POSTGRES_HOST: postgres
          # The default PostgreSQL port
          POSTGRES_PORT: 5432

Para más información, consulta Acerca de los contenedores de servicios.