{"meta":{"title":"Migrando de CI/CD do GitLab para GitHub Actions","intro":"GitHub Actions e GitLab CI/CD compartilham várias semelhanças de configuração, o que faz com que a migração para GitHub Actions seja relativamente simples.","product":"GitHub Actions","breadcrumbs":[{"href":"/pt/actions","title":"GitHub Actions"},{"href":"/pt/actions/tutorials","title":"Tutoriais"},{"href":"/pt/actions/tutorials/migrate-to-github-actions","title":"Migrar para o GitHub Actions"},{"href":"/pt/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"Migrações manuais"},{"href":"/pt/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"Migrar do GitLab CI/CD"}],"documentType":"article"},"body":"# Migrando de CI/CD do GitLab para GitHub Actions\n\nGitHub Actions e GitLab CI/CD compartilham várias semelhanças de configuração, o que faz com que a migração para GitHub Actions seja relativamente simples.\n\n## Introdução\n\nO GitLab CI/CD e GitHub Actions permitem criar fluxos de trabalho que criam, testam, publicam, lançam e implantam códigos automaticamente. O GitLab CI/CD e GitHub Actions compartilham algumas semelhanças na configuração do fluxo de trabalho:\n\n* Os arquivos de configuração do fluxo de trabalho são gravados YAML e armazenados no repositório do código.\n* Os fluxos de trabalho incluem um ou mais trabalhos.\n* Os trabalhos incluem uma ou mais etapas ou comandos individuais.\n* Os trabalhos podem ser executados em máquinas gerenciadas ou auto-hospedadas.\n\nExistem algumas diferenças e este guia irá mostrar a você as diferenças importantes para que você possa fazer a migração do seu fluxo de trabalho para GitHub Actions.\n\n## Trabalhos\n\nOs trabalhos no GitLab CI/CD são muito semelhantes aos trabalhos em GitHub Actions. Em ambos os sistemas, os trabalhos têm as características a seguir:\n\n* Os trabalhos contêm uma série de etapas ou scripts executados sequencialmente.\n* Os trabalhos podem ser executados em máquinas separadas ou em contêineres separados.\n* Por padrão, os trabalhos são executados em paralelo, mas podem ser configurados para serem executados sequencialmente.\n\nVocê pode executar um script ou um comando de shell em um trabalho. Na CI/CD do GitLab, as etapas de script são especificadas por meio da chave `script`. No GitHub Actions, todos os scripts são especificados por meio da chave `run`.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para trabalhos\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### Sintaxe do GitHub Actions para trabalhos\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## Executores\n\nOs executores são máquinas nas quais os trabalhos são executados. Tanto o GitLab CI/CD quanto o GitHub Actions oferecem variantes de executores gerenciados e auto-hospedados. Na CI/CD do GitLab, `tags` são usadas para executar trabalhos em diferentes plataformas, enquanto no GitHub Actions, isso é feito com a chave `runs-on`.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para executores\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### Sintaxe de GitHub Actions para executores\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 saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on).\n\n## Imagens do Docker\n\nTanto o GitLab CI/CD quanto o GitHub Actions são compatíveis com trabalhos executados em uma imagem do Docker. Na CI/CD do GitLab, as imagens do Docker são definidas com uma chave `image`, enquanto no GitHub Actions isso é feito com a chave `container`.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para imagens do Docker\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### Sintaxe do GitHub Actions para imagens do Docker\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\nPara saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer).\n\n## Condição e sintaxe de expressão\n\nA CI/CD do GitLab usa `rules` para determinar se um trabalho será executado para uma condição específica. O GitHub Actions usa a palavra-chave `if` para impedir que um trabalho seja executado, a menos que uma condição seja atendida.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para condições e expressões\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### Sintaxe do GitHub Actions para condições e expressões\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 saber mais, confira [Avaliar expressões em fluxos de trabalho e ações](/pt/actions/learn-github-actions/expressions).\n\n## Dependências entre trabalhos\n\nTanto o GitLab CI/CD quanto o GitHub Actions permitem que você defina dependências para um trabalho. Nos dois sistemas, os trabalhos são executados em paralelo por padrão, mas as dependências de trabalho no GitHub Actions podem ser especificadas explicitamente com a chave `needs`. A CI/CD do GitLab também tem um conceito de `stages`, em que os trabalhos em uma fase são executados simultaneamente, mas a próxima fase será iniciada quando todos os trabalhos da fase anterior tiverem sido concluídos. Você pode recriar esse cenário no GitHub Actions com a chave `needs`.\n\nAbaixo, há um exemplo da sintaxe para cada sistema. Os fluxos de trabalho começam com dois trabalhos chamados `build_a` e `build_b` em execução em paralelo e, quando esses trabalhos forem concluídos, outro trabalho chamado `test_ab` será executado. Por fim, quando `test_ab` é concluído, o trabalho `deploy_ab` será executado.\n\n### Sintaxe de CI/CD do GitLab para dependências entre trabalhos\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### Sintaxe do GitHub Actions para dependências entre trabalhos\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 saber mais, confira [Sintaxe de fluxo de trabalho para o GitHub Actions](/pt/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds).\n\n## Agendar fluxos de trabalho\n\nTanto o GitLab CI/CD quanto o GitHub Actions permitem que você execute fluxos de trabalho em um intervalo específico. No GitLab CI/CD, os agendamentos de pipelines são configurados através da interface do usuário, enquanto em GitHub Actions, você pode acionar um workflow em um intervalo programado com a palavra-chave \"on\".\n\nPara saber mais, confira [Eventos que disparam fluxos de trabalho](/pt/actions/using-workflows/events-that-trigger-workflows#scheduled-events).\n\n## Variáveis e segredos\n\nA CI/CD do GitLab e do GitHub Actions dão suporte à definição de variáveis no pipeline ou no arquivo de configuração do fluxo de trabalho, bem como à criação de segredos usando o GitLab ou a interface de usuário do GitHub.\n\nPara saber mais, confira [Armazenar informações em variáveis](/pt/actions/learn-github-actions/variables) e [Segredos](/pt/actions/security-for-github-actions/security-guides/about-secrets).\n\n## Armazenamento em cache\n\nGitLab CI/CD e GitHub Actions fornecem um método no arquivo de configuração para armazenar os arquivos do fluxo de trabalho manualmente.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para cacheamento\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### Sintaxe do GitHub Actions para cache\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## Artifacts\n\nTanto o GitLab CI/CD quanto o GitHub Actions podem fazer upload de arquivos e diretórios criados por um trabalho como artefatos. Em GitHub Actions, os artefatos podem ser usados para persistir dados em várias tarefas.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para artefatos\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### Sintaxe de GitHub Actions para artefatos\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 saber mais, confira [Armazenar e compartilhar dados com artefatos de fluxo de trabalho](/pt/actions/using-workflows/storing-workflow-data-as-artifacts).\n\n## Bancos de dados e contêineres de serviço\n\nAmbos os sistemas permitem que você inclua contêineres adicionais para bases de dados, memorização ou outras dependências.\n\nNa CI/CD do GitLab, um contêiner para o trabalho é especificado com a chave `image`, enquanto o GitHub Actions usa a chave `container`. Nos dois sistemas, contêineres de serviço adicionais são especificados com a chave `services`.\n\nAbaixo, há um exemplo da sintaxe para cada sistema.\n\n### Sintaxe de CI/CD do GitLab para bancos de dados e contêineres de serviço\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### Sintaxe do GitHub Actions para bancos de dados e contêineres de serviço\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 saber mais, confira [Comunicar-se com os contêineres de serviço do Docker](/pt/actions/using-containerized-services/about-service-containers)."}