Introduction
GitLab CI/CD et GitHub Actions les deux vous permettent de créer des flux de travail qui créent, testent, publient, publient et déploient automatiquement du code. GitLab CI/CD et GitHub Actions présentent certaines similitudes dans la configuration du pipeline :
- Les fichiers de configuration de workflow sont écrits en YAML et sont stockés dans le dépôt du code.
- Les workflows comportent un ou plusieurs travaux.
- Les travaux incluent une ou plusieurs étapes ou commandes individuelles.
- Les travaux peuvent s’exécuter sur des machines gérées ou auto-hébergées.
Il existe quelques différences, et ce guide vous montre les différences importantes afin que vous puissiez migrer votre flux de travail vers GitHub Actions.
travaux
Les travaux dans GitLab CI/CD sont très similaires aux travaux dans GitHub Actions. Dans les deux systèmes, les travaux présentent les caractéristiques suivantes :
- Les travaux contiennent une série d’étapes ou de scripts qui s’exécutent de manière séquentielle.
- Les travaux peuvent s’exécuter sur des machines distinctes ou dans des conteneurs distincts.
- Les travaux s’exécutent en parallèle par défaut, mais peuvent être configurés pour s’exécuter séquentiellement.
Vous pouvez exécuter un script ou une commande shell dans un travail. Dans GitLab CI/CD, les étapes de script sont spécifiées à l’aide de la clé script. Dans GitHub Actions, tous les scripts sont spécifiés à l’aide de la run clé.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour les travaux
job1:
variables:
GIT_CHECKOUT: "true"
script:
- echo "Run your script here"
GitHub Actions syntaxe des tâches
jobs:
job1:
steps:
- uses: actions/checkout@v6
- run: echo "Run your script here"
Coureurs
Les exécuteurs sont des ordinateurs sur lesquels les travaux s’exécutent. GitLab CI/CD et GitHub Actions proposent tous deux des exécuteurs hébergés et des exécuteurs auto-hébergés. Dans GitLab CI/CD, tags sont utilisés pour exécuter des tâches sur différentes plateformes, tandis que dans GitHub Actions, cela se fait avec la clé runs-on.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour les exécuteurs
windows_job:
tags:
- windows
script:
- echo Hello, %USERNAME%!
linux_job:
tags:
- linux
script:
- echo "Hello, $USER!"
Syntaxe GitHub Actions pour les exécuteurs
windows_job:
runs-on: windows-latest
steps:
- run: echo Hello, %USERNAME%!
linux_job:
runs-on: ubuntu-latest
steps:
- run: echo "Hello, $USER!"
Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Images Docker
GitLab CI/CD et GitHub Actions prennent en charge l’exécution de jobs dans une image Docker. Dans GitLab CI/CD, les images Docker sont définies à l’aide de la clé image, tandis que dans GitHub Actions, cela se fait avec la clé container.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour les images Docker
my_job:
image: node:20-bookworm-slim
GitHub Actions syntaxe pour les images Docker
jobs:
my_job:
container: node:20-bookworm-slim
Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Syntaxe de condition et d’expression
GitLab CI/CD utilise rules pour déterminer si un job s’exécutera pour une condition donnée.
GitHub Actions utilise le if mot clé pour empêcher l’exécution d’un travail, sauf si une condition est remplie.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD de GitLab pour des conditions et des expressions
deploy_prod:
stage: deploy
script:
- echo "Deploy to production server"
rules:
- if: '$CI_COMMIT_BRANCH == "master"'
GitHub Actions syntaxe pour les conditions et les expressions
jobs:
deploy_prod:
if: contains( github.ref, 'master')
runs-on: ubuntu-latest
steps:
- run: echo "Deploy to production server"
Pour plus d’informations, consultez « Évaluer des expressions dans les workflows et les actions. ».
Dépendances entre les travaux
GitLab CI/CD et GitHub Actions vous permettent de définir des dépendances pour un travail. Dans les deux systèmes, les travaux s’exécutent en parallèle par défaut, mais les dépendances de travail peuvent être spécifiées GitHub Actions explicitement avec la needs clé. GitLab CI/CD a également un concept de stages, où les travaux d’une phase s’exécutent simultanément, mais la phase suivante commence lorsque tous les travaux de la phase précédente sont terminés. Vous pouvez recréer ce scénario dans GitHub Actions avec la touche needs.
Voici un exemple de syntaxe pour chaque système. Les workflows commencent avec deux travaux nommés build_a et build_b exécutés en parallèle et, une fois ces travaux terminés, un autre travail appelé test_ab s’exécute. Enfin, lorsque test_ab est terminé, la tâche deploy_ab s'exécutera.
Syntaxe CI/CD GitLab pour les dépendances entre les travaux
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"
GitHub Actions syntaxe des dépendances entre les tâches
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"
Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».
Planification des workflows
GitLab CI/CD et GitHub Actions vous permettent d’exécuter des flux de travail à un intervalle spécifique. Dans GitLab CI/CD, les planifications de pipeline sont configurées avec l’interface utilisateur, tandis que dans GitHub Actions vous pouvez déclencher un flux de travail à intervalle planifié avec la clé « on ».
Pour plus d’informations, consultez « Événements qui déclenchent des flux de travail ».
Variables et secrets
GitLab CI/CD et GitHub Actions permettent de définir des variables dans le fichier de configuration du pipeline ou du workflow, et de créer des secrets à l’aide de l’interface utilisateur de GitLab ou de GitHub.
Pour plus d’informations, consultez « Stocker des informations dans des variables » et « Secrets ».
Mise en cache
GitLab CI/CD et GitHub Actions fournissez une méthode dans le fichier de configuration pour mettre en cache manuellement les fichiers de flux de travail.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour la mise en 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
GitHub Actions syntaxe pour la mise en cache
jobs:
test_async:
runs-on: ubuntu-latest
steps:
- name: Cache node modules
uses: actions/cache@v4
with:
path: ~/.npm
key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
restore-keys: v1-npm-deps-
Artefacts
GitLab CI/CD et GitHub Actions peuvent téléverser des fichiers et des répertoires créés par un job en tant qu’artefacts. Dans GitHub Actions, les artefacts peuvent être utilisés pour stocker des données de manière persistante entre plusieurs tâches.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour les artefacts
script:
artifacts:
paths:
- math-homework.txt
GitHub Actions syntaxe des artefacts
- name: Upload math result for job 1
uses: actions/upload-artifact@v4
with:
name: homework
path: math-homework.txt
Pour plus d’informations, consultez « Stocker et partager des données avec les artefacts de workflow ».
Bases de données et conteneurs de service
Les deux systèmes vous permettent d’inclure des conteneurs supplémentaires pour les bases de données, la mise en cache ou d’autres dépendances.
Dans GitLab CI/CD, un conteneur pour le travail est spécifié avec la image clé, tandis qu’il GitHub Actions utilise la container clé. Dans les deux systèmes, des conteneurs de service supplémentaires sont spécifiés avec la clé services.
Voici un exemple de syntaxe pour chaque système.
Syntaxe CI/CD GitLab pour les bases de données et les conteneurs de service
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
GitHub Actions syntaxe pour les bases de données et les conteneurs de service
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@v6
# 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
Pour plus d’informations, consultez « Communication avec les conteneurs de service Docker ».