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

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.

Sintaxe de CI/CD do GitLab para trabalhos

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

Sintaxe do GitHub Actions para trabalhos

jobs:
  job1:
    steps:
      - uses: actions/checkout@v4
      - 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.

Sintaxe de CI/CD do GitLab para executores

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

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

Sintaxe de GitHub Actions para executores

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 para o 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.

Sintaxe de CI/CD do GitLab para imagens do Docker

my_job:
  image: node:20-bookworm-slim

Sintaxe do GitHub Actions para imagens do Docker

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

Para obter mais informações, confira "Sintaxe de fluxo de trabalho para o 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.

Sintaxe de CI/CD do GitLab para condições e expressões

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

Sintaxe do GitHub Actions para condições e expressões

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 "Avaliar expressões em fluxos de trabalho e açõ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.

Sintaxe de CI/CD do GitLab para dependências entre trabalhos

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"

Sintaxe do GitHub Actions para dependências entre trabalhos

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 para o 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

A CI/CD do GitLab e 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 de GitHub Enterprise Server.

Para obter mais informações, confira "Armazenar informações em variáveis" e "Usar segredos em ações do GitHub."

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.

Sintaxe de CI/CD do GitLab para cache

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

Sintaxe do GitHub Actions para cache

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.

Sintaxe de CI/CD do GitLab para artefatos

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

Sintaxe de GitHub Actions para artefatos

- 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 "Armazenando e compartilhando dados de um fluxo de trabalho".

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.

Sintaxe de CI/CD do GitLab para bancos de dados e contêineres de serviço

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

Sintaxe do GitHub Actions para bancos de dados e contêineres de serviço

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