{"meta":{"title":"Migration de GitLab CI/CD vers GitHub Actions","intro":"GitHub Actions et GitLab CI/CD partagent plusieurs similitudes de configuration, ce qui facilite grandement la migration vers GitHub Actions.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/actions","title":"GitHub Actions"},{"href":"/fr/actions/tutorials","title":"Tutoriels"},{"href":"/fr/actions/tutorials/migrate-to-github-actions","title":"Migrer vers GitHub Actions"},{"href":"/fr/actions/tutorials/migrate-to-github-actions/manual-migrations","title":"Migrations manuelles"},{"href":"/fr/actions/tutorials/migrate-to-github-actions/manual-migrations/migrate-from-gitlab-cicd","title":"Migrer depuis GitLab CI/CD"}],"documentType":"article"},"body":"# Migration de GitLab CI/CD vers GitHub Actions\n\nGitHub Actions et GitLab CI/CD partagent plusieurs similitudes de configuration, ce qui facilite grandement la migration vers GitHub Actions.\n\n## Introduction\n\nGitLab 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 :\n\n* Les fichiers de configuration de workflow sont écrits en YAML et sont stockés dans le dépôt du code.\n* Les workflows comportent un ou plusieurs travaux.\n* Les travaux incluent une ou plusieurs étapes ou commandes individuelles.\n* Les travaux peuvent s’exécuter sur des machines gérées ou auto-hébergées.\n\nIl existe quelques différences, et ce guide vous montre les différences importantes afin que vous puissiez migrer votre workflow vers GitHub Actions.\n\n## travaux\n\nLes 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 :\n\n* Les travaux contiennent une série d’étapes ou de scripts qui s’exécutent de manière séquentielle.\n* Les travaux peuvent s’exécuter sur des machines distinctes ou dans des conteneurs distincts.\n* Les travaux s’exécutent en parallèle par défaut, mais peuvent être configurés pour s’exécuter séquentiellement.\n\nVous 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 clé `run`.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour les travaux\n\n```yaml\njob1:\n  variables:\n    GIT_CHECKOUT: \"true\"\n  script:\n    - echo \"Run your script here\"\n```\n\n### Syntaxe GitHub Actions pour les travaux\n\n```yaml\njobs:\n  job1:\n    steps:\n      - uses: actions/checkout@v6\n      - run: echo \"Run your script here\"\n```\n\n## Coureurs\n\nLes exécuteurs sont des ordinateurs sur lesquels les travaux s’exécutent. GitLab CI/CD et GitHub Actions offrent des variantes gérées et auto-hébergées des runners. 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`.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour les exécuteurs\n\n```yaml\nwindows_job:\n  tags:\n    - windows\n  script:\n    - echo Hello, %USERNAME%!\n\nlinux_job:\n  tags:\n    - linux\n  script:\n    - echo \"Hello, $USER!\"\n```\n\n### Syntaxe GitHub Actions pour les exécuteurs\n\n```yaml\nwindows_job:\n  runs-on: windows-latest\n  steps:\n    - run: echo Hello, %USERNAME%!\n\nlinux_job:\n  runs-on: ubuntu-latest\n  steps:\n    - run: echo \"Hello, $USER!\"\n```\n\nPour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idruns-on) ».\n\n## Images Docker\n\nGitLab 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`.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour les images Docker\n\n```yaml\nmy_job:\n  image: node:20-bookworm-slim\n```\n\n### Syntaxe GitHub Actions pour les images Docker\n\n```yaml\njobs:\n  my_job:\n    container: node:20-bookworm-slim\n```\n\nPour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idcontainer) ».\n\n## Syntaxe de condition et d’expression\n\nGitLab CI/CD utilise `rules` pour déterminer si un job s’exécutera pour une condition donnée. GitHub Actions utilise le mot clé `if` pour empêcher l’exécution d’un travail, sauf si une condition est remplie.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD de GitLab pour des conditions et des expressions\n\n```yaml\ndeploy_prod:\n  stage: deploy\n  script:\n    - echo \"Deploy to production server\"\n  rules:\n    - if: '$CI_COMMIT_BRANCH == \"master\"'\n```\n\n### Syntaxe GitHub Actions pour les conditions et les expressions\n\n```yaml\njobs:\n  deploy_prod:\n    if: contains( github.ref, 'master')\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"Deploy to production server\"\n```\n\nPour plus d’informations, consultez « [Évaluer des expressions dans les workflows et les actions.](/fr/actions/learn-github-actions/expressions) ».\n\n## Dépendances entre les travaux\n\nGitLab 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`.\n\nVoici 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.\n\n### Syntaxe CI/CD GitLab pour les dépendances entre les travaux\n\n```yaml\nstages:\n  - build\n  - test\n  - deploy\n\nbuild_a:\n  stage: build\n  script:\n    - echo \"This job will run first.\"\n\nbuild_b:\n  stage: build\n  script:\n    - echo \"This job will run first, in parallel with build_a.\"\n\ntest_ab:\n  stage: test\n  script:\n    - echo \"This job will run after build_a and build_b have finished.\"\n\ndeploy_ab:\n  stage: deploy\n  script:\n    - echo \"This job will run after test_ab is complete\"\n```\n\n### Syntaxe GitHub Actions pour les dépendances entre les tâches\n\n```yaml\njobs:\n  build_a:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first.\"\n\n  build_b:\n    runs-on: ubuntu-latest\n    steps:\n      - run: echo \"This job will be run first, in parallel with build_a\"\n\n  test_ab:\n    runs-on: ubuntu-latest\n    needs: [build_a,build_b]\n    steps:\n      - run: echo \"This job will run after build_a and build_b have finished\"\n\n  deploy_ab:\n    runs-on: ubuntu-latest\n    needs: [test_ab]\n    steps:\n      - run: echo \"This job will run after test_ab is complete\"\n```\n\nPour plus d’informations, consultez « [Syntaxe de flux de travail pour GitHub Actions](/fr/actions/using-workflows/workflow-syntax-for-github-actions#jobsjob_idneeds) ».\n\n## Planification des workflows\n\nGitLab 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 ».\n\nPour plus d’informations, consultez « [Événements qui déclenchent des flux de travail](/fr/actions/using-workflows/events-that-trigger-workflows#scheduled-events) ».\n\n## Variables et secrets\n\nGitLab CI/CD et GitHub Actions permettent de définir des variables dans le fichier de configuration du pipeline ou du flux de travail, et de créer des secrets à l'aide de l'interface utilisateur de GitLab ou de GitHub. UI.\n\nPour plus d’informations, consultez « [Stocker des informations dans des variables](/fr/actions/learn-github-actions/variables) » et « [Secrets](/fr/actions/security-for-github-actions/security-guides/about-secrets) ».\n\n## Mise en cache\n\nGitLab CI/CD et GitHub Actions fournissent une méthode dans le fichier de configuration pour mettre manuellement en cache les fichiers de workflow.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour la mise en cache\n\n```yaml\nimage: node:latest\n\ncache:\n  key: $CI_COMMIT_REF_SLUG\n  paths:\n    - .npm/\n\nbefore_script:\n  - npm ci --cache .npm --prefer-offline\n\ntest_async:\n  script:\n    - node ./specs/start.js ./specs/async.spec.js\n```\n\n### Syntaxe GitHub Actions pour la mise en cache\n\n```yaml\njobs:\n  test_async:\n    runs-on: ubuntu-latest\n    steps:\n    - name: Cache node modules\n      uses: actions/cache@v4\n      with:\n        path: ~/.npm\n        key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}\n        restore-keys: v1-npm-deps-\n```\n\n## Artefacts\n\nGitLab 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.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour les artefacts\n\n```yaml\nscript:\nartifacts:\n  paths:\n    - math-homework.txt\n```\n\n### Syntaxe GitHub Actions pour les artéfacts\n\n```yaml\n- name: Upload math result for job 1\n  uses: actions/upload-artifact@v4\n  with:\n    name: homework\n    path: math-homework.txt\n```\n\nPour plus d’informations, consultez « [Stocker et partager des données avec les artefacts de workflow](/fr/actions/using-workflows/storing-workflow-data-as-artifacts) ».\n\n## Bases de données et conteneurs de service\n\nLes 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.\n\nDans 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`.\n\nVoici un exemple de syntaxe pour chaque système.\n\n### Syntaxe CI/CD GitLab pour les bases de données et les conteneurs de service\n\n```yaml\ncontainer-job:\n  variables:\n    POSTGRES_PASSWORD: postgres\n    # The hostname used to communicate with the\n    # PostgreSQL service container\n    POSTGRES_HOST: postgres\n    # The default PostgreSQL port\n    POSTGRES_PORT: 5432\n  image: node:20-bookworm-slim\n  services:\n    - postgres\n  script:\n    # Performs a clean installation of all dependencies\n    # in the `package.json` file\n    - npm ci\n    # Runs a script that creates a PostgreSQL client,\n    # populates the client with data, and retrieves data\n    - node client.js\n  tags:\n    - docker\n```\n\n### Syntaxe GitHub Actions pour les bases de données et les conteneurs de service\n\n```yaml\njobs:\n  container-job:\n    runs-on: ubuntu-latest\n    container: node:20-bookworm-slim\n\n    services:\n      postgres:\n        image: postgres\n        env:\n          POSTGRES_PASSWORD: postgres\n\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v6\n\n      # Performs a clean installation of all dependencies\n      # in the `package.json` file\n      - name: Install dependencies\n        run: npm ci\n\n      - name: Connect to PostgreSQL\n        # Runs a script that creates a PostgreSQL client,\n        # populates the client with data, and retrieves data\n        run: node client.js\n        env:\n          # The hostname used to communicate with the\n          # PostgreSQL service container\n          POSTGRES_HOST: postgres\n          # The default PostgreSQL port\n          POSTGRES_PORT: 5432\n```\n\nPour plus d’informations, consultez « [Communication avec les conteneurs de service Docker](/fr/actions/using-containerized-services/about-service-containers) »."}