{"meta":{"title":"Migración de CI/CD de GitLab a Acciones de GitHub","intro":"GitHub Actions y GitLab CI/CD comparten varias similitudes de configuración, lo que hace que la migración a GitHub Actions sea relativamente sencilla.","product":"GitHub Actions","breadcrumbs":[{"href":"/es/actions","title":"GitHub Actions"},{"href":"/es/actions/tutorials","title":"Tutoriales"},{"href":"/es/actions/tutorials/migrate-to-github-actions","title":"Migrar a GitHub Actions"},{"href":"/es/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"Migraciones manuales"},{"href":"/es/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"Migrar desde GitLab CI/CD"}],"documentType":"article"},"body":"# Migración de CI/CD de GitLab a Acciones de GitHub\n\nGitHub Actions y GitLab CI/CD comparten varias similitudes de configuración, lo que hace que la migración a GitHub Actions sea relativamente sencilla.\n\n## Introducción\n\nGitLab CI/CD y GitHub Actions ambos le permiten crear flujos de trabajo que compilen, prueben, publiquen, publiquen e implementen código automáticamente. GitLab CI/CD y GitHub Actions comparten algunas similitudes en la configuración del flujo de trabajo:\n\n* Los archivos de configuración de flujo de trabajo están escritas en YAML y se almacenan en el repositorio del código.\n* Los flujos de trabajo incluyen una o más tareas.\n* Los trabajos incluyen uno o más pasos o comandos individuales.\n* Las tareas pueden ejecutarse ya sea en máquinas administradas o autogestionadas.\n\nHay algunas diferencias y esta guía le mostrará las diferencias importantes para poder migrar el flujo de trabajo a GitHub Actions.\n\n## Trabajos\n\nLos jobs de GitLab CI/CD son muy similares a los de GitHub Actions. En ambos sistemas, los jobs tienen las siguientes características:\n\n* Los jobs contienen una serie de pasos o scripts que se ejecutan secuencialmente.\n* Los trabajos pueden ejecutarse en máquinas separadas o en contenedores separados.\n* Los jobs se ejecutan en paralelo predeterminadamente, pero pueden configurarse para ejecutarse en secuencia.\n\nPuedes 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 mediante la `run` clave .\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para trabajos\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### GitHub Actions sintaxis de las tareas\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## Ejecutores\n\nLos ejecutores son máquinas en donde se ejecutan los jobs. Tanto CI/CD de GitLab como GitHub Actions ofrecen variantes administradas y autohospedadas de ejecutores. En CI/CD de GitLab, `tags` se usan para ejecutar trabajos en distintas plataformas, mientras que en GitHub Actions se hace con la clave `runs-on`.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para ejecutores\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### Sintaxis de GitHub Actions para ejecutores\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\nPara más información, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idruns-on).\n\n## Imágenes de Docker\n\nTanto CI/CD de GitLab como GitHub Actions admiten la ejecución de trabajos en una imagen de Docker. En CI/CD de GitLab, las imágenes de Docker se definen con la clave `image`, mientras que en GitHub Actions se hace con la clave `container`.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para imágenes de Docker\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### GitHub Actions sintaxis de imágenes de Docker\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\nPara más información, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idcontainer).\n\n## Sintaxis de condiciones y expresiones\n\nEn CI/CD de GitLab se usa `rules` para determinar si un trabajo se ejecutará para una condición específica.\nGitHub Actions usa la `if` palabra clave para evitar que se ejecute un trabajo a menos que se cumpla una condición.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para condiciones y expresiones\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### GitHub Actions sintaxis de condiciones y expresiones\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\nPara más información, consulta [Evaluación de expresiones en flujos de trabajo y acciones](/es/actions/reference/workflows-and-actions/expressions).\n\n## Dependencias entre los Jobs\n\nTanto GitLab CI/CD como GitHub Actions le permiten establecer dependencias para una tarea. En ambos sistemas, los trabajos se ejecutan en paralelo de forma predeterminada, pero las dependencias de trabajo de GitHub Actions se pueden especificar explícitamente con la `needs` clave. 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. Puede recrear este escenario en GitHub Actions con la tecla `needs`.\n\nA 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`.\n\n### Sintaxis de CI/CD de GitLab para dependencias entre trabajos\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### GitHub Actions sintaxis de dependencias entre trabajos\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\nPara más información, consulta [Sintaxis del flujo de trabajo para Acciones de GitHub](/es/actions/reference/workflows-and-actions/workflow-syntax#jobsjob_idneeds).\n\n## Programar flujos de trabajo\n\nTanto GitLab CI/CD como GitHub Actions le permiten ejecutar flujos de trabajo a intervalos específicos. En CI/CD de GitLab, las programaciones de canalización se configuran con la IU, mientras que en las GitHub Actions puede desencadenar un flujo de trabajo en un intervalo programado con la clave \"on\".\n\nPara más información, consulta [Eventos que desencadenan flujos de trabajo](/es/actions/reference/workflows-and-actions/events-that-trigger-workflows#schedule).\n\n## Variables y secretos\n\nGitLab CI/CD y GitHub Actions permiten configurar variables en el archivo de configuración de la canalización o del flujo de trabajo, y crear secretos mediante la interfaz de usuario de GitLab o GitHub.\n\nPara más información, consulta [Almacenamiento de información en variables](/es/actions/how-tos/write-workflows/choose-what-workflows-do/use-variables) y [Secretos](/es/actions/concepts/security/secrets).\n\n## Almacenamiento en memoria caché\n\nCI/CD de GitLab y GitHub Actions proporciona un método en el archivo de configuración para almacenar en caché manualmente los archivos de flujo de trabajo.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para almacenamiento en caché\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### GitHub Actions sintaxis para el almacenamiento en caché\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artefactos\n\nTanto GitLab CI/CD como GitHub Actions pueden subir archivos y directorios generados por un job como artefactos. En GitHub Actions, los artefactos se pueden usar para conservar los datos entre varios trabajos.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para artefactos\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### Sintaxis de GitHub Actions para artefactos\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\nPara más información, consulta [Almacenamiento y uso compartido de datos con artefactos de flujo de trabajo](/es/actions/tutorials/store-and-share-data).\n\n## Bases de datos y contenedores de servicios\n\nAmbos sistemas te permiten incluir contenedores adicionales para bases de datos, almacenamiento en caché, u otras dependencias.\n\nEn GitLab CI/CD, se especifica un contenedor para el job con la clave `image`, mientras que GitHub Actions usa la clave `container`. En ambos sistemas, se especifican contenedores de servicio adicionales con la clave `services`.\n\nA continuación encontrarás un ejemplo de la sintaxis para cada sistema.\n\n### Sintaxis de CI/CD de GitLab para bases de datos y contenedores de servicios\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### GitHub Actions sintaxis para bases de datos y contenedores de servicios\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\nPara más información, consulta [Comunicación con contenedores de servicios de Docker](/es/actions/tutorials/use-containerized-services/use-docker-service-containers)."}