Migration de GitLab CI/CD vers GitHub Actions

Introduction

GitLab CI/CD et GitHub Actions vous permettent tous deux de créer des workflows qui génèrent, testent, publient, libèrent et déploient automatiquement du code. GitLab CI/CD et GitHub Actions partagent certaines similitudes dans la configuration de workflow :

• 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 workflow 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 d’environnement 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 clé run.

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"

Syntaxe GitHub Actions pour les travaux

jobs:
  job1:
    steps:
      - uses: actions/checkout@v4
      - run: echo "Run your script here"

Exécuteurs

Les exécuteurs sont des ordinateurs sur lesquels les travaux s’exécutent. GitLab CI/CD et GitHub Actions offrent des variantes managées et auto-hébergées des exécuteurs. Dans GitLab CI/CD, des tags sont utilisées pour exécuter des travaux sur différentes plateformes, tandis que dans GitHub Actions, cette opération est effectuée 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 « Workflow syntax for GitHub Actions ».

docker images

GitLab CI/CD et GitHub Actions prennent en charge l’exécution de travaux dans une image Docker. Dans GitLab CI/CD, les images Docker sont définies avec une clé image, tandis que dans GitHub Actions, cette opération est effectuée 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:10.16-jessie

Syntaxe GitHub Actions pour les images Docker

jobs:
  my_job:
    container: node:10.16-jessie

Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Syntaxe de condition et d’expression

GitLab CI/CD utilise des rules pour déterminer si un travail s’exécutera pour une condition spécifique. GitHub Actions utilise le mot clé if 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 GitLab pour les conditions et expressions

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

Syntaxe GitHub Actions pour les conditions et 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 « Expressions ».

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 travaux dans GitHub Actions peuvent être spécifiées explicitement avec la clé needs. 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 clé 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, une fois test_ab terminé, le travail deploy_ab s’exécute.

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"

Syntaxe GitHub Actions pour les dépendances entre les travaux

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 « Workflow syntax for GitHub Actions ».

Planification des workflows

GitLab CI/CD et GitHub Actions vous permettent d’exécuter des workflows à un intervalle spécifique. Dans GitLab CI/CD, les planifications de pipelines sont configurées avec l’interface utilisateur, tandis que dans GitHub Actions, vous pouvez déclencher un workflow selon un 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 prennent en charge la définition des variables dans le fichier de configuration du pipeline ou du workflow, et la création de secrets à l’aide de l’interface utilisateur GitLab ou GitHub Enterprise Server.

Pour plus d’informations, consultez « Variables » et « Utilisation de secrets dans GitHub Actions ».

Mise en cache

GitLab CI/CD et GitHub Actions fournissent une méthode dans le fichier de configuration pour mettre manuellement en cache les fichiers de workflow.

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

Syntaxe GitHub Actions pour la mise en 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

GitLab CI/CD et GitHub Actions peuvent charger des fichiers et des répertoires créés par un travail en tant qu’artefacts. Dans GitHub Actions, les artefacts peuvent être utilisés pour conserver des données entre plusieurs travaux.

Voici un exemple de syntaxe pour chaque système.

Syntaxe CI/CD GitLab pour les artefacts

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

Syntaxe GitHub Actions pour les artefacts

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

Pour plus d’informations, consultez « Stockage des données de workflow en tant qu’artefacts ».

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 clé image, tandis que GitHub Actions utilise la clé container. 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: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

Syntaxe GitHub Actions pour les bases de données et les conteneurs de service

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

Pour plus d’informations, consultez « À propos des conteneurs de service ».