Migration de Travis CI vers GitHub Actions

Remarque

Les exécuteurs hébergés sur GitHub Enterprise Server ne sont pas pris en charge sur GitHub.

Introduction

Ce guide vous aide à migrer de Travis CI vers GitHub Actions. Il compare leurs concepts et leur syntaxe, décrit les similitudes et illustre leurs différentes approches des tâches courantes.

Avant de commencer

Avant de commencer votre migration vers GitHub Actions, il serait utile de vous familiariser avec son fonctionnement :

Pour obtenir un exemple rapide qui illustre un GitHub Actions travail, consultez Démarrage rapide pour GitHub Actions.
Pour découvrir les concepts essentiels GitHub Actions , consultez Présentation des GitHub Actions.

Comparaison de l’exécution des travaux

Pour vous permettre de contrôler le moment où les tâches CI sont exécutées, un GitHub Actions_flux de travail_ utilise des travaux qui s’exécutent en parallèle par défaut. Chaque travail contient des étapes exécutées dans une séquence que vous définissez. Si vous devez exécuter des actions d’installation et de nettoyage pour un travail, vous pouvez définir des étapes dans chaque travail pour effectuer ces opérations.

Similitudes clés

GitHub Actions et Travis CI partagent certaines similitudes, et la compréhension de ces éléments à l’avance peut aider à faciliter le processus de migration.

Utilisation de la syntaxe YAML

Travis CI et GitHub Actions les deux utilisent YAML pour créer des travaux et des workflows, et ces fichiers sont stockés dans le référentiel du code. Pour plus d’informations sur l’utilisation GitHub Actions de YAML, consultez Création d’un exemple de workflow.

Variables personnalisées

Travis CI vous permet de définir des variables et de les partager entre les phases. De même, GitHub Actions vous pouvez définir des variables pour un flux de travail. Pour plus d’informations, consultez « Stocker des informations dans des variables ».

Les variables par défaut

Travis CI et GitHub Actions les deux incluent des variables d’environnement par défaut que vous pouvez utiliser dans vos fichiers YAML. Pour GitHub Actionscela, vous pouvez voir ces éléments répertoriés dans Références des variables.

Traitement parallèle des travaux

Travis CI peut utiliser des stages pour exécuter des travaux en parallèle. De même, GitHub Actions s’exécute jobs en parallèle. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Badges d’état

Travis CI et GitHub Actions les deux badges d’état de prise en charge, ce qui vous permet d’indiquer si une build passe ou échoue. Pour plus d’informations, consultez « Ajout d’un badge d’état de flux de travail ».

Utilisation d’une matrice

Travis CI et GitHub Actions les deux prennent en charge une matrice, ce qui vous permet d’effectuer des tests à l’aide de combinaisons de systèmes d’exploitation et de packages logiciels. Pour plus d’informations, consultez « Exécution de variantes de tâches dans un workflow ».

Voici un exemple qui compare la syntaxe pour chaque système.

Syntaxe Travis CI pour une matrice

matrix:
  include:
    - rvm: '2.5'
    - rvm: '2.6.3'

GitHub Actions syntaxe d’une matrice

jobs:
  build:
    strategy:
      matrix:
        ruby: ['2.5', '2.6.3']

Ciblage de branches spécifiques

Travis CI et GitHub Actions les deux vous permettent de cibler votre ci à une branche spécifique. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Voici un exemple de syntaxe pour chaque système.

Syntaxe Travis CI pour cibler des branches spécifiques

branches:
  only:
    - main
    - 'mona/octocat'

GitHub Actions syntaxe pour cibler des branches spécifiques

on:
  push:
    branches:
      - main
      - 'mona/octocat'

Vérification des sous-modules

Travis CI et GitHub Actions les deux vous permettent de contrôler si les sous-modules sont inclus dans le clone du référentiel.

Voici un exemple de syntaxe pour chaque système.

Syntaxe Travis CI pour la vérification des sous-modules

git:
  submodules: false

GitHub Actions syntaxe pour extraire les sous-modules

- uses: actions/checkout@v6
  with:
    submodules: false

Utilisation de variables d’environnement dans une matrice

Travis CI et GitHub Actions peut ajouter des variables personnalisées à une matrice de test, ce qui vous permet de faire référence à la variable dans une étape ultérieure.

Dans GitHub Actions, vous pouvez utiliser la include clé pour ajouter des variables d’environnement personnalisées à une matrice. Dans cet exemple, les entrées de matrice pour node-version sont configurées pour utiliser des valeurs différentes pour les variables d’environnement site et datacenter. L’étape Echo site details utilise ensuite env: ${{ matrix.env }} pour faire référence aux variables personnalisées :

name: Node.js CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    strategy:
      matrix:
       include:
         - node-version: '14.x'
           site: "prod"
           datacenter: "site-a"
         - node-version: '16.x'
           site: "dev"
           datacenter: "site-b"
    steps:
      - name: Echo site details
        env:
          SITE: ${{ matrix.site }}
          DATACENTER: ${{ matrix.datacenter }}
        run: echo $SITE $DATACENTER

Fonctionnalités clés dans GitHub Actions

Lors de la migration à partir de Travis CI, tenez compte des fonctionnalités clés suivantes dans GitHub Actions:

Stockage des secrets

GitHub Actions vous permet de stocker des secrets et de les référencer dans vos travaux. GitHub Actions les organisations peuvent limiter les dépôts qui peuvent accéder aux secrets de l’organisation. Les règles de protection du déploiement peuvent nécessiter une approbation manuelle pour qu’un flux de travail accède aux secrets de l’environnement. Pour plus d’informations, consultez « Secrets ».

GitHub Actions inclut la prise en charge intégrée du stockage d’artefacts, ce qui vous permet de partager des fichiers entre des travaux dans un flux de travail. Vous pouvez également enregistrer les fichiers résultants et les partager avec d’autres workflows. Pour plus d’informations, consultez « Présentation des GitHub Actions ».

Hébergement de vos propres exécuteurs

Si vos travaux nécessitent un matériel ou un logiciel spécifique, GitHub Actions vous pouvez héberger vos propres exécuteurs et leur envoyer vos travaux à des fins de traitement. GitHub Actions vous permet également d’utiliser des stratégies pour contrôler l’accès à ces exécuteurs, en lui accordant l’accès au niveau de l’organisation ou du référentiel. Pour plus d’informations, consultez « Gestion des exécuteurs auto-hébergés ».

Utilisation de différentes langues dans GitHub Actions

Lorsque vous travaillez avec différentes langues, GitHub Actionsvous pouvez créer une étape dans votre travail pour configurer vos dépendances linguistiques. Pour plus d’informations sur l’utilisation d’un langage particulier, consultez Génération et test de votre code.

Exécution des scripts

GitHub Actions peut utiliser run des étapes pour exécuter des scripts ou des commandes shell. Pour utiliser un shell particulier, vous pouvez spécifier le type shell lors de la fourniture du chemin au script. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Par exemple :

steps:
  - name: Run build script
    run: ./.github/scripts/build.sh
    shell: bash

Gestion des erreurs dans GitHub Actions

Lors de la migration vers GitHub Actions, il existe différentes approches de gestion des erreurs dont vous devrez peut-être prendre connaissance.

Gestion des erreurs de script

GitHub Actions arrête un travail immédiatement si l’une des étapes retourne un code d’erreur. Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ».

Gestion des erreurs de travail

GitHub Actions utilise if des conditions pour exécuter des travaux ou des étapes dans certaines situations. Par exemple, vous pouvez exécuter une étape quand une autre étape entraîne un failure(). Pour plus d’informations, consultez « Syntaxe de flux de travail pour GitHub Actions ». Vous pouvez également utiliser continue-on-error pour empêcher l’arrêt de l’exécution d’un workflow quand un travail échoue.

Migration de la syntaxe pour les expressions et les conditions

Pour exécuter des travaux sous des expressions conditionnelles, Travis CI et GitHub Actions partager une syntaxe de condition similaire if . GitHub Actions vous permet d’utiliser le if conditionnel pour empêcher l’exécution d’un travail ou d’une étape, sauf si une condition est remplie. Pour plus d’informations, consultez « Évaluer des expressions dans les workflows et les actions. ».

Cet exemple montre comment une condition if peut contrôler si une étape est exécutée :

jobs:
  conditional:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This step runs with str equals 'ABC' and num equals 123"
        if: env.str == 'ABC' && env.num == 123

Migration de phases vers des étapes

Où Travis CI utilise des phases pour exécuter des étapes, GitHub Actions comporte des étapes qui exécutent des actions. Vous pouvez trouver des actions prédéfinies dans le GitHub Marketplace, ou vous pouvez créer vos propres actions. Pour plus d’informations, consultez « Réutilisation des automatisations ».

Voici un exemple de syntaxe pour chaque système.

Syntaxe Travis CI pour les phases et les étapes

language: python
python:
  - "3.7"

script:
  - python script.py

GitHub Actions syntaxe pour les étapes et les actions

jobs:
  run_python:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/setup-python@v5
        with:
          python-version: '3.7'
          architecture: 'x64'
      - run: python script.py

Mise en cache des dépendances

Travis CI et GitHub Actions vous permet de mettre en cache manuellement les dépendances pour une réutilisation ultérieure.

Ces exemples illustrent la syntaxe du cache pour chaque système.

Syntaxe Travis CI pour la mise en cache

language: node_js
cache: npm

syntaxe GitHub Actions pour la mise en cache

- name: Cache node modules
  uses: actions/cache@v4
  with:
    path: ~/.npm
    key: v1-npm-deps-${{ hashFiles('**/package-lock.json') }}
    restore-keys: v1-npm-deps-

env:
  - MAVEN_PATH="/usr/local/maven"

GitHub Actions workflow avec une variable d’environnement

jobs:
  maven-build:
    env:
      MAVEN_PATH: '/usr/local/maven'

Développement avec Node.js

Travis CI pour la construction avec Node.js

install:
  - npm install
script:
  - npm run build
  - npm test

GitHub Actions flux de travail pour la création avec Node.js

name: Node.js CI
on: [push]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v6
      - name: Use Node.js
        uses: actions/setup-node@v4
        with:
          node-version: '16.x'
      - run: npm install
      - run: npm run build
      - run: npm test

Étapes suivantes

Pour continuer à en savoir plus sur les principales fonctionnalités de GitHub Actions, consultez Écriture de workflows.

Dans cet article