Skip to main content

Fazer a migração do GitLab CI/CD para o GitHub Actions

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.

Introdução

O 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:

  • Os arquivos de configuração do fluxo de trabalho são gravados YAML e armazenados no repositório do código.
  • Os fluxos de trabalho incluem um ou mais trabalhos.
  • Os trabalhos incluem uma ou mais etapas ou comandos individuais.
  • Os trabalhos podem ser executados em máquinas gerenciadas ou auto-hospedadas.

Existem 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.

Trabalhos

Os 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:

  • Os trabalhos contêm uma série de etapas ou scripts executados sequencialmente.
  • Os trabalhos podem ser executados em máquinas separadas ou em contêineres separados.
  • Por padrão, os trabalhos executados em paralelo, mas podem ser configuradas para serem executados em sequência.

Você 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.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
job1:
  variables:
    GIT_CHECKOUT: "true"
  script:
    - echo "Run your script here"
jobs:
  job1:
    steps:
      - uses: actions/checkout@v3
      - run: echo "Run your script here"

Executores

Os executores são máquinas nas quais os trabalhos são executados. Tanto GitLab CI/CD quanto GitHub Actions oferecem variantes de executores gerenciadas e auto-hospedadas. 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.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
windows_job:
  tags:
    - windows
  script:
    - echo Hello, %USERNAME%!

linux_job: tags:
    - linux script:
    - echo "Hello, $USER!"
windows_job:
  runs-on: windows-latest
  steps:
    - run: echo Hello, %USERNAME%!

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

Para obter mais informações, confira "Sintaxe de fluxo de trabalho do GitHub Actions".

Docker images

Tanto 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.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
my_job:
  image: node:10.16-jessie
jobs:
  my_job:
    container: node:10.16-jessie

Para obter mais informações, confira "Sintaxe de fluxo de trabalho do GitHub Actions".

Condição e sintaxe de expressão

A 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.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
deploy_prod:
  stage: deploy
  script:
    - echo "Deploy to production server"
  rules:
    - if: '$CI_COMMIT_BRANCH == "master"'
jobs:
  deploy_prod:
    if: contains( github.ref, 'master')
    runs-on: ubuntu-latest
    steps:
      - run: echo "Deploy to production server"

Para obter mais informações, confira "Expressões".

Dependências entre trabalhos

Tanto 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.

Abaixo, 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.

GitLab CI/CD GitHub Actions
stages:
  - build
  - test
  - deploy

build_a: stage: build script:
    - echo "Esse trabalho será executado primeiro".

build_b: stage: build script:
    - echo "Esse trabalho será executado primeiro, em paralelo com build_a".

test_ab: stage: test script:
    - echo "Esse trabalho será executado depois que build_a e build_b forem concluídos".

deploy_ab: stage: deploy script:
    - echo "Esse trabalho será executado após a conclusão de test_ab"
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 obter mais informações, confira "Sintaxe de fluxo de trabalho do GitHub Actions".

Agendar fluxos de trabalho

Tanto o GitLab CI/CD quanto o GitHub Actions permitem que você execute fluxos de trabalho em um intervalo específico. No GitLab CI/CD, a programação de pipeline é configurada com a interface do usuário, enquanto em GitHub Actions você pode acionar um fluxo de trabalho em um intervalo programado com a chave "ligado".

Para obter mais informações, confira "Eventos que disparam fluxos de trabalho".

Variáveis e segredos

O GitLab CI/CD e GitHub Actions são compatíveis com as variáveis de ambiente no pipeline ou no arquivo de configuração do fluxo de trabalho e ao criar segredos usando o GitLab ou a interface de usuário de GitHub Enterprise Cloud.

Para obter mais informações, confira "Variáveis de ambiente" e "Segredos criptografados".

Cache

GitLab CI/CD e GitHub Actions fornecem um método no arquivo de configuração para armazenar os arquivos do fluxo de trabalho manualmente.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
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
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 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ários trabalhos.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
script:
artifacts:
  paths:
    - math-homework.txt
- name: Upload math result for job 1
  uses: actions/upload-artifact@v3
  with:
    name: homework
    path: math-homework.txt

Para obter mais informações, confira "Como armazenar dados de fluxo de trabalho como artefatos".

Bancos de dados e contêineres de serviço

Ambos os sistemas permitem que você inclua contêineres adicionais para bases de dados, memorização ou outras dependências.

Na 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.

Abaixo, há um exemplo da sintaxe para cada sistema:

GitLab CI/CD GitHub Actions
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:10.18-jessie
  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
jobs:
  container-job:
    runs-on: ubuntu-latest
    container: node:10.18-jessie

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

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

      # 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 obter mais informações, confira "Sobre os contêineres de serviço".