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. No GitLab CI/CD, as etapas do script são especificadas usando a chave do script. Em GitHub Actions, todos os scripts são especificados usando a chave executar.

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

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

jobs:
  job1:
    steps:
      - uses: actions/checkout@v2
      - 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. No GitLab CI/CD, as tags são usadas para executar trabalhos em diferentes plataformas, enquanto em GitHub Actions é feito com a chave runs-on.

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

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, consulte "Sintaxe do fluxo de trabalho para GitHub Actions."

Imagens do Docker

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 de imagem, enquanto em GitHub Actions, isso é feito com a chave contêiner.

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

my_job:
  image: node:10.16-jessie

jobs:
  my_job:
    container: node:10.16-jessie

Para obter mais informações, consulte "Sintaxe de fluxo de trabalho para o GitHub Actions".

Condição e sintaxe de expressão

O GitLab CI/CD usa as regras para determinar se um trabalho será executado para uma condição específica. GitHub Actions usa a palavra-chave se para evitar que um trabalho seja executado a menos que uma condição seja atendida.

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

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, consulte "Expressões".

Dependências entre trabalhos

Tanto o GitLab CI/CD quanto o GitHub Actions permitem que você defina dependências para um trabalho. Em ambos os sistemas, os trabalhos executados em paralelo por padrão, mas dependências de trabalho em GitHub Actions podem ser especificados explicitamente com a chave needs. O GitLab CI/CD também tem o conceito de stages, em que os trabalhos em um estágio são executados paralelamente, mas o próximo stage terá início depois de terminados todos os trabalho no stage anterior. Você pode recriar esse cenário em GitHub Actions com a chave needs.

Abaixo, há um exemplo da sintaxe para cada sistema. Os fluxos de trabalho iniciam com dois trabalhos denominados build_a e build_b sendo executados paralelamente e, após a conclusão desses trabalhos, será executado outro trabalho denominado test_ab. Por fim, quando test_ab é concluído, o trabalho deploy_ab será executado.

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"

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, consulte "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, consulte "Eventos que acionam 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 Server.

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

Armazenar em 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:

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@v2
      with:
        path: ~/.npm
        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
        restore-keys: v1-npm-deps-

O cache de GitHub Actions só é aplicável para repositórios hospedados em GitHub.com. Para obter mais informações, consulte "Memorizar dependências para acelerar fluxos de trabalho".

Artefatos

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:

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

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

Para obter mais informações, consulte "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.

No GitLab CI/CD, um contêiner para o trabalho é especificado com a chave imagem, enquanto GitHub Actions usa a chave contêiner. Nos dois sistemas, os contêineres de serviço adicionais são especificados com a chave serviços.

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

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@v2

      # 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, consulte "Sobre contêineres de serviço."