Migration d’Azure Pipelines vers GitHub Actions

Introduction

Azure Pipelines 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. Azure Pipelines 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 étapes ou les tâches peuvent être réutilisées et partagées avec la communauté.

Pour plus d’informations, consultez « Comprendre GitHub Actions ».

Différences clés

Lors de la migration à partir d’Azure Pipelines, tenez compte des différences suivantes :

• Azure Pipelines prend en charge un éditeur classique hérité, qui vous permet de définir votre configuration CI dans un éditeur d’interface utilisateur graphique au lieu de créer la définition de pipeline dans un fichier YAML. GitHub Actions utilise des fichiers YAML pour définir des workflows et ne prend pas en charge un éditeur graphique.
• Azure Pipelines vous permet d’omettre une structure dans les définitions de travaux. Par exemple, si vous n’avez qu’un seul travail, vous n’avez pas besoin de définir le travail, mais uniquement ses étapes. GitHub Actions nécessite une configuration explicite et la structure YAML ne peut pas être omise.
• Azure Pipelines prend en charge les phases définies dans le fichier YAML, qui peuvent être utilisées pour créer des workflows de déploiement. GitHub Actions vous oblige à séparer les phases en fichiers de workflow YAML distincts.
• Les agents de build Azure Pipelines locaux peuvent être sélectionnés avec des fonctionnalités. Les exécuteurs auto-hébergés GitHub Actions peuvent être sélectionnés avec des étiquettes.

Migration des travaux et des étapes

Les travaux et les étapes dans Azure Pipelines sont très similaires aux travaux et aux étapes dans GitHub Actions. Dans les deux systèmes, les travaux présentent les caractéristiques suivantes :

• Les travaux contiennent une série d’étapes qui s’exécutent de manière séquentielle.
• Les travaux s’exécutent sur des machines virtuelles 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.

Migration des étapes de script

Vous pouvez exécuter un script ou une commande d’environnement en tant qu’étape dans un workflow. Dans Azure Pipelines, les étapes de script peuvent être spécifiées à l’aide de la clé script ou des clés bash, powershell ou pwsh. Les scripts peuvent également être spécifiés en tant qu’entrée de la tâche Bash ou de la tâche PowerShell.

Dans GitHub Actions, tous les scripts sont spécifiés à l’aide de la clé run. Pour sélectionner un shell particulier, vous pouvez spécifier la clé shell lors de la fourniture du script. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Voici un exemple de syntaxe pour chaque système.

Syntaxe Azure Pipelines pour les étapes de script

jobs:
  - job: scripts
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in the default shell"
      - bash: echo "This step runs in bash"
      - pwsh: Write-Host "This step runs in PowerShell Core"
      - task: PowerShell@2
        inputs:
          script: Write-Host "This step runs in PowerShell"

Syntaxe GitHub Actions pour les étapes de script

jobs:
  scripts:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in the default shell"
      - run: echo "This step runs in bash"
        shell: bash
      - run: Write-Host "This step runs in PowerShell Core"
        shell: pwsh
      - run: Write-Host "This step runs in PowerShell"
        shell: powershell

Différences dans la gestion des erreurs de script

Dans Azure Pipelines, les scripts peuvent être configurés pour retourner une erreur si une sortie est envoyée à stderr. GitHub Actions ne prend pas en charge cette configuration.

GitHub Actions configure les shells pour passer en « mode Fail-fast » dans la mesure du possible, ce qui arrête immédiatement le script si l’une des commandes d’un script se termine avec un code d’erreur. En revanche, Azure Pipelines nécessite une configuration explicite pour quitter immédiatement en cas d’erreur. Pour plus d’informations, consultez « Workflow syntax for GitHub Actions ».

Différences dans l’interface par défaut sur Windows

Dans Azure Pipelines, l’interface par défaut pour les scripts sur les plateformes Windows est l’interface de commande (cmd.exe). Dans GitHub Actions, l’interface par défaut pour les scripts sur les plateformes Windows est PowerShell. PowerShell présente plusieurs différences dans les commandes intégrées, l’expansion de variables et le contrôle de flux.

Si vous exécutez une commande simple, vous pouvez exécuter un script d’interface de commande dans PowerShell sans aucune modification. Toutefois, dans la plupart des cas, vous devez mettre à jour votre script avec la syntaxe PowerShell ou demander à GitHub Actions d’exécuter le script avec l’interface de commande au lieu de PowerShell. Pour ce faire, spécifiez shell comme cmd.

Voici un exemple de syntaxe pour chaque système.

Syntaxe Azure Pipelines utilisant CMD par défaut

jobs:
  - job: run_command
    pool:
      vmImage: 'windows-latest'
    steps:
      - script: echo "This step runs in CMD on Windows by default"

Syntaxe GitHub Actions pour la spécification de CMD

jobs:
  run_command:
    runs-on: windows-latest
    steps:
      - run: echo "This step runs in PowerShell on Windows by default"
      - run: echo "This step runs in CMD on Windows explicitly"
        shell: cmd

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

Migration de la syntaxe des expressions et conditions

Azure Pipelines et GitHub Actions peuvent exécuter des étapes de manière conditionnelle. Dans Azure Pipelines, les expressions conditionnelles sont spécifiées à l’aide de la clé condition. Dans GitHub Actions, les expressions conditionnelles sont spécifiées à l’aide de la clé if.

Azure Pipelines utilise des fonctions dans des expressions pour exécuter des étapes de manière conditionnelle. En revanche, GitHub Actions utilise une notation infixe. Par exemple, vous devez remplacer la fonction eq dans Azure Pipelines par l’opérateur == dans GitHub Actions.

Voici un exemple de syntaxe pour chaque système.

Syntaxe Azure Pipelines pour les expressions conditionnelles

jobs:
  - job: conditional
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This step runs with str equals 'ABC' and num equals 123"
        condition: and(eq(variables.str, 'ABC'), eq(variables.num, 123))

Syntaxe GitHub Actions pour les expressions conditionnelles

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

Pour plus d’informations, consultez « Évaluer les expressions dans les workflows et les actions ».

Dépendances entre les travaux

Azure Pipelines 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 peuvent être spécifiées explicitement. Dans Azure Pipelines, cette opération est effectuée avec la clé dependsOn. Dans GitHub Actions, cette opération est effectuée avec la clé needs.

Voici un exemple de syntaxe pour chaque système. Les workflows démarrent un premier travail nommé initialet, une fois ce travail terminé, deux travaux nommés fanout1 et fanout2 s’exécutent. Enfin, une fois ces travaux terminés, le travail fanin s’exécute.

Syntaxe Azure Pipelines pour les dépendances entre les travaux

jobs:
  - job: initial
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - script: echo "This job will be run first."
  - job: fanout1
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout2."
  - job: fanout2
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: initial
    steps:
      - script: echo "This job will run after the initial job, in parallel with fanout1."
  - job: fanin:
    pool:
      vmImage: 'ubuntu-latest'
    dependsOn: [fanout1, fanout2]
    steps:
      - script: echo "This job will run after fanout1 and fanout2 have finished."

Syntaxe GitHub Actions pour les dépendances entre les travaux

jobs:
  initial:
    runs-on: ubuntu-latest
    steps:
      - run: echo "This job will be run first."
  fanout1:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout2."
  fanout2:
    runs-on: ubuntu-latest
    needs: initial
    steps:
      - run: echo "This job will run after the initial job, in parallel with fanout1."
  fanin:
    runs-on: ubuntu-latest
    needs: [fanout1, fanout2]
    steps:
      - run: echo "This job will run after fanout1 and fanout2 have finished."

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

Migration de tâches vers des actions

Azure Pipelines utilise des tâches, qui sont des composants d’application qui peuvent être réutilisés dans plusieurs workflows. GitHub Actions utilise des actions qui peuvent être utilisées pour effectuer des tâches et personnaliser votre workflow. Dans les deux systèmes, vous pouvez spécifier le nom de la tâche ou de l’action à exécuter, ainsi que toutes les entrées requises sous forme de paires clé/valeur.

Voici un exemple de syntaxe pour chaque système.

Syntaxe Azure Pipelines pour les tâches

jobs:
  - job: run_python
    pool:
      vmImage: 'ubuntu-latest'
    steps:
      - task: UsePythonVersion@0
        inputs:
          versionSpec: '3.7'
          architecture: 'x64'
      - script: python script.py

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

Vous pouvez trouver des actions que vous pouvez utiliser dans votre workflow dans GitHub Marketplace, ou vous pouvez créer vos propres actions. Pour plus d’informations, consultez « Partage des automatisations ».