{"meta":{"title":"Génération et test de code PowerShell","intro":"Découvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet PowerShell.","product":"GitHub Actions","breadcrumbs":[{"href":"/fr/enterprise-server@3.20/actions","title":"GitHub Actions"},{"href":"/fr/enterprise-server@3.20/actions/tutorials","title":"Tutoriels"},{"href":"/fr/enterprise-server@3.20/actions/tutorials/build-and-test-code","title":"Générer et tester du code"},{"href":"/fr/enterprise-server@3.20/actions/tutorials/build-and-test-code/powershell","title":"PowerShell"}],"documentType":"article"},"body":"# Génération et test de code PowerShell\n\nDécouvrez comment créer un flux de travail d’intégration continue (CI) pour générer et tester votre projet PowerShell.\n\n> \\[!NOTE]\n> Les exécuteurs hébergés sur GitHub ne sont pas pris en charge sur GitHub Enterprise Server.\n\n## Introduction\n\nCe guide explique comment utiliser PowerShell pour l’intégration continue. Il décrit comment utiliser Pester, installer des dépendances, tester votre module et publier sur le PowerShell Gallery.\n\nLes exécuteurs hébergés dans GitHub ont un cache d’outils où sont préinstallés des logiciels, notamment PowerShell et Pester.\n\nPour obtenir la liste complète des logiciels les plus récents et des versions préinstallées de PowerShell et Pester, consultez « [Exécuteurs hébergés par GitHub](/fr/enterprise-server@3.20/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software) ».\n\n## Prérequis\n\nVous devez être familiarisé avec YAML et la syntaxe GitHub Actions. Pour plus d’informations, consultez « [Écriture de workflows](/fr/enterprise-server@3.20/actions/learn-github-actions) ».\n\nIl est recommandé de connaître les bases de PowerShell et de Pester. Pour plus d'informations, consultez les pages suivantes :\n\\*\n[Premiers pas avec PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)\n\\*\n[Pester](https://pester.dev)\n\n### Utilisation d’exécuteurs auto-hébergés sur GitHub Enterprise Server\n\nQuand vous utilisez des actions de configuration (comme `actions/setup-LANGUAGE`) sur GitHub Enterprise Server avec des exécuteurs auto-hébergés, vous pouvez être amené à configurer le cache des outils sur les exécuteurs qui n’ont pas accès à Internet. Pour plus d’informations, consultez « [Configuration du cache d’outils sur les exécuteurs auto-hébergés sans accès à Internet](/fr/enterprise-server@3.20/admin/github-actions/managing-access-to-actions-from-githubcom/setting-up-the-tool-cache-on-self-hosted-runners-without-internet-access) ».\n\n## Ajout d’un workflow pour Pester\n\nPour automatiser vos tests avec PowerShell et Pester, vous pouvez ajouter un workflow qui s’exécute chaque fois qu’une modification est poussée vers votre dépôt. Dans l’exemple suivant, `Test-Path` permet de vérifier la présence d’un fichier nommé `resultsfile.log`.\n\nCet exemple de fichier de workflow doit être ajouté au répertoire de votre dépôt `.github/workflows/` :\n\n```yaml\nname: Test PowerShell on Ubuntu\non: push\n\njobs:\n  pester-test:\n    name: Pester test\n    runs-on: ubuntu-latest\n    steps:\n      - name: Check out repository code\n        uses: actions/checkout@v5\n      - name: Perform a Pester test from the command-line\n        shell: pwsh\n        run: Test-Path resultsfile.log | Should -Be $true\n      - name: Perform a Pester test from the Tests.ps1 file\n        shell: pwsh\n        run: |\n          Invoke-Pester Unit.Tests.ps1 -Passthru\n```\n\n* ```\n          `shell: pwsh` - Configure le travail pour qu’il utilise PowerShell lors de l’exécution des commandes `run`.\n  ```\n\n* ```\n          `run: Test-Path resultsfile.log` - Vérifie si un fichier nommé `resultsfile.log` se trouve dans le répertoire racine du dépôt.\n  ```\n\n* ```\n          `Should -Be $true` - Utilise Pester pour définir un résultat attendu. Si le résultat est inattendu, GitHub Actions le signale comme un échec de test. Par exemple :\n  ```\n\n  ![Capture d’écran d’un échec d’exécution de workflow pour un test Pester. Le test indique « Expected $true, but got $false » et « Error: Process completed with exit code 1 ».](/assets/images/help/repository/actions-failed-pester-test-updated.png)\n\n* ```\n          `Invoke-Pester Unit.Tests.ps1 -Passthru` - Utilise Pester pour exécuter des tests définis dans un fichier nommé `Unit.Tests.ps1`. Par exemple, pour effectuer le même test que celui décrit ci-dessus, `Unit.Tests.ps1` contiendra les éléments suivants :\n  ```\n\n  ```powershell\n  Describe \"Check results file is present\" {\n      It \"Check results file is present\" {\n          Test-Path resultsfile.log | Should -Be $true\n      }\n  }\n  ```\n\n## Emplacements des modules PowerShell\n\nLe tableau ci-dessous décrit les emplacements des différents modules PowerShell pour chaque exécuteur hébergé dans GitHub.\n\n<div class=\"ghd-tool rowheaders\">\n\n|   | Ubuntu | macOS | Windows |\n| - | ------ | ----- | ------- |\n|   |        |       |         |\n\n```\n          **Modules système PowerShell** |`/opt/microsoft/powershell/7/Modules/*`|`/usr/local/microsoft/powershell/7/Modules/*`|`C:\\program files\\powershell\\7\\Modules\\*`|\n```\n\n|\n**Modules complémentaires PowerShell**|`/usr/local/share/powershell/Modules/*`|`/usr/local/share/powershell/Modules/*`|`C:\\Modules\\*`|\n|\n**Modules installés par l’utilisateur**|`/home/runner/.local/share/powershell/Modules/*`|`/Users/runner/.local/share/powershell/Modules/*`|`C:\\Users\\runneradmin\\Documents\\PowerShell\\Modules\\*`|\n\n</div>\n\n> \\[!NOTE]\n> Sur les exécuteurs Ubuntu, les modules Azure PowerShell sont stockés dans `/usr/share/` au lieu de l’emplacement par défaut des modules complémentaires PowerShell (par exemple, `/usr/local/share/powershell/Modules/`).\n\n## Installer les dépendances\n\nLes exécuteurs hébergés dans GitHub ont PowerShell 7 et Pester installés. Vous pouvez utiliser `Install-Module` pour installer des dépendances supplémentaires à partir de l’PowerShell Gallery avant de générer et de tester votre code.\n\n> \\[!NOTE]\n> Les packages préinstallés (tels que Pester) qui sont utilisés par les exécuteurs hébergés dans GitHub sont régulièrement mis à jour et peuvent entraîner des modifications importantes. Par conséquent, il est recommandé de toujours spécifier les versions de package nécessaires à l’aide de `Install-Module` avec `-MaximumVersion`.\n\nVous pouvez également mettre en cache vos dépendances pour accélérer vos exécutions de workflow. Pour plus d’informations, consultez « [Référence sur la mise en cache des dépendances](/fr/enterprise-server@3.20/actions/using-workflows/caching-dependencies-to-speed-up-workflows) ».\n\nPar exemple, le travail suivant installe les modules `SqlServer` et `PSScriptAnalyzer` :\n\n```yaml\njobs:\n  install-dependencies:\n    name: Install dependencies\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v5\n      - name: Install from PSGallery\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module SqlServer, PSScriptAnalyzer\n```\n\n> \\[!NOTE]\n> Par défaut, aucun dépôt n’est approuvé par PowerShell. Lors de l’installation de modules à partir du PowerShell Gallery, vous devez définir explicitement la stratégie d’installation pour `PSGallery` sur `Trusted`.\n\n### Mise en cache des dépendances\n\nVous pouvez mettre en cache les dépendances PowerShell à l’aide d’une clé unique, ce qui vous permet de restaurer les dépendances pour les prochains workflows avec l’action [`cache`](https://github.com/marketplace/actions/cache). Pour plus d’informations, consultez « [Référence sur la mise en cache des dépendances](/fr/enterprise-server@3.20/actions/using-workflows/caching-dependencies-to-speed-up-workflows) ».\n\nPowerShell met en cache ses dépendances à différents emplacements, selon le système d’exploitation de l’exécuteur. Par exemple, l’emplacement `path` utilisé dans l’exemple Ubuntu suivant sera différent pour un système d’exploitation Windows.\n\n```yaml\nsteps:\n  - uses: actions/checkout@v5\n  - name: Setup PowerShell module cache\n    id: cacher\n    uses: actions/cache@v4\n    with:\n      path: \"~/.local/share/powershell/Modules\"\n      key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer\n  - name: Install required PowerShell modules\n    if: steps.cacher.outputs.cache-hit != 'true'\n    shell: pwsh\n    run: |\n      Set-PSRepository PSGallery -InstallationPolicy Trusted\n      Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop\n```\n\n## Test de votre code\n\nVous pouvez utiliser les mêmes commandes que celles que vous utilisez localement pour générer et tester votre code.\n\n### Utilisation de PSScriptAnalyzer pour linter du code\n\nL’exemple suivant installe `PSScriptAnalyzer`, et l’utilise pour effectuer le linting de tous les fichiers `ps1` du dépôt. Pour plus d’informations, consultez [PSScriptAnalyzer sur GitHub](https://github.com/PowerShell/PSScriptAnalyzer).\n\n```yaml\n  lint-with-PSScriptAnalyzer:\n    name: Install and run PSScriptAnalyzer\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v5\n      - name: Install PSScriptAnalyzer module\n        shell: pwsh\n        run: |\n          Set-PSRepository PSGallery -InstallationPolicy Trusted\n          Install-Module PSScriptAnalyzer -ErrorAction Stop\n      - name: Lint with PSScriptAnalyzer\n        shell: pwsh\n        run: |\n          Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues\n          $errors   = $issues.Where({$_.Severity -eq 'Error'})\n          $warnings = $issues.Where({$_.Severity -eq 'Warning'})\n          if ($errors) {\n              Write-Error \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\" -ErrorAction Stop\n          } else {\n              Write-Output \"There were $($errors.Count) errors and $($warnings.Count) warnings total.\"\n          }\n```\n\n## Empaquetage des données de workflow en tant qu’artefacts\n\nVous pouvez charger des artefacts à afficher une fois un workflow terminé. Par exemple, vous devrez peut-être enregistrer des fichiers journaux, des vidages principaux, des résultats de test ou des captures d’écran. Pour plus d’informations, consultez « [Stocker et partager des données avec les artefacts de workflow](/fr/enterprise-server@3.20/actions/using-workflows/storing-workflow-data-as-artifacts) ».\n\nL’exemple suivant montre comment utiliser l’action `upload-artifact` pour archiver les résultats des tests reçus de `Invoke-Pester`. Pour plus d’informations, consultez l’action [`upload-artifact`](https://github.com/actions/upload-artifact).\n\n```yaml\nname: Upload artifact from Ubuntu\n\non: [push]\n\njobs:\n  upload-pester-results:\n    name: Run Pester and upload results\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v5\n      - name: Test with Pester\n        shell: pwsh\n        run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml\n      - name: Upload test results\n        uses: actions/upload-artifact@v3\n        with:\n          name: ubuntu-Unit-Tests\n          path: Unit.Tests.xml\n    if: ${{ always() }}\n```\n\nLa fonction `always()` configure le travail de manière à poursuivre le traitement, même en cas d’échec du test. Pour plus d’informations, consultez « [Référence des contextes](/fr/enterprise-server@3.20/actions/learn-github-actions/contexts#always) ».\n\n## Publication dans PowerShell Gallery\n\nVous pouvez configurer votre flux de travail pour publier votre module PowerShell sur le PowerShell Gallery lorsque vos tests CI réussissent. Vous pouvez utiliser des secrets pour stocker n’importe quels jetons ou informations d’identification nécessaires à la publication de votre package. Pour plus d’informations, consultez « [Utilisation de secrets dans GitHub Actions](/fr/enterprise-server@3.20/actions/security-guides/using-secrets-in-github-actions) ».\n\nL’exemple suivant crée un package et utilise `Publish-Module` pour le publier dans l’PowerShell Gallery :\n\n```yaml\nname: Publish PowerShell Module\n\non:\n  release:\n    types: [created]\n\njobs:\n  publish-to-gallery:\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v5\n      - name: Build and publish\n        env:\n          NUGET_KEY: ${{ secrets.NUGET_KEY }}\n        shell: pwsh\n        run: |\n          ./build.ps1 -Path /tmp/samplemodule\n          Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose\n```"}