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 saber mais, 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 saber mais, 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 saber mais, 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 saber mais, 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 saber mais, 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.
Para saber mais, 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@v4
with:
name: homework
path: math-homework.txt
Para saber mais, 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 saber mais, confira Sobre os contêineres de serviço.