{"meta":{"title":"Erstellen und Testen eines PowerShell-Projekts","intro":"Hier erfährst, du, wie du einen CI-Workflow (Continuous Integration) erstellst, um dein PowerShell-Projekt zu erstellen und zu testen.","product":"GitHub Actions","breadcrumbs":[{"href":"/de/actions","title":"GitHub Actions"},{"href":"/de/actions/tutorials","title":"Anleitungen"},{"href":"/de/actions/tutorials/build-and-test-code","title":"Erstellen und Testen von Code"},{"href":"/de/actions/tutorials/build-and-test-code/powershell","title":"PowerShell"}],"documentType":"article"},"body":"# Erstellen und Testen eines PowerShell-Projekts\n\nHier erfährst, du, wie du einen CI-Workflow (Continuous Integration) erstellst, um dein PowerShell-Projekt zu erstellen und zu testen.\n\nGithub-gehostete Runner für Unternehmen\n\n## Einführung\n\nIn diesem Leitfaden wird gezeigt, wie du PowerShell für CI verwendest. Es beschreibt, wie Sie Pester verwenden, Abhängigkeiten installieren, Ihr Modul testen und auf dem PowerShell Gallery veröffentlichen.\n\nGitHub-gehostete Runner haben einen Toolcache mit vorinstallierter Software, die PowerShell und Pester einschließt.\n\nEine vollständige Liste der aktuellen Software und der vorinstallierten Versionen von PowerShell und Pester findest du unter [Von GitHub gehostete Runner](/de/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software).\n\n## Voraussetzungen\n\nDu solltest mit YAML und der Syntax für GitHub Actions vertraut sein. Weitere Informationen finden Sie unter [Schreiben von Workflows](/de/actions/learn-github-actions).\n\nDu solltest ein grundlegendes Verständnis von PowerShell und Pester haben. Weitere Informationen findest du unter\n\n* [Getting started with PowerShell](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started) (Erste Schritte mit PowerShell)\n* [Pester](https://pester.dev)\n\n## Hinzufügen eines Workflows für Pester\n\nUm deine Tests mit PowerShell und Pester zu automatisieren, kannst du einen Workflow hinzufügen, der jedes Mal ausgeführt wird, wenn eine Änderung an dein Repository gepusht wird. Im folgenden Beispiel wird `Test-Path` verwendet, um zu überprüfen, ob eine Datei namens `resultsfile.log` vorhanden ist.\n\nDiese Datei mit dem Beispielworkflow muss im Verzeichnis `.github/workflows/` deines Repositorys hinzugefügt werden:\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@v6\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* `shell: pwsh` konfiguriert den Auftrag für die Verwendung von PowerShell beim Ausführen der `run`-Befehle.\n\n* `run: Test-Path resultsfile.log` überprüft, ob eine Datei namens `resultsfile.log` im Stammverzeichnis des Repositorys vorhanden ist.\n\n* `Should -Be $true` verwendet Pester, um ein erwartetes Ergebnis zu definieren. Wenn das Ergebnis unerwartet ist, markiert GitHub Actions dies als fehlerhaften Test. Beispiel:\n\n  ![Screenshot eines Fehlers bei der Workflow-Ausführung für einen Pester-Test. Der Test meldet „Expected $true, but got $false“ und „Error: Process completed with exit code 1.“](/assets/images/help/repository/actions-failed-pester-test-updated.png)\n\n* `Invoke-Pester Unit.Tests.ps1 -Passthru` verwendet Pester zum Ausführen von Tests, die in einer Datei mit dem Namen `Unit.Tests.ps1` definiert sind. Wenn du beispielsweise den oben beschriebenen Test ausführen möchtest, enthält `Unit.Tests.ps1` Folgendes:\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## Speicherorte der PowerShell-Module\n\nDie folgende Tabelle zeigt für jeden GitHub-gehosteten Runner den Speicherort der einzelnen PowerShell-Module.\n\n<div class=\"ghd-tool rowheaders\">\n\n|                                             | Ubuntu                                           | macOS                                             | Windows                                               |\n| ------------------------------------------- | ------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------- |\n| **PowerShell-Systemmodule**                 | `/opt/microsoft/powershell/7/Modules/*`          | `/usr/local/microsoft/powershell/7/Modules/*`     | `C:\\program files\\powershell\\7\\Modules\\*`             |\n| **PowerShell-Add-On-Module**                | `/usr/local/share/powershell/Modules/*`          | `/usr/local/share/powershell/Modules/*`           | `C:\\Modules\\*`                                        |\n| **Von Benutzer\\*innen installierte Module** | `/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> Auf Ubuntu-Läufern werden Azure PowerShell Module in `/usr/share/` anstelle des Standardspeicherorts von PowerShell-Add-On-Modulen (d. h. `/usr/local/share/powershell/Modules/`) gespeichert.\n\n## Installieren von Abhängigkeiten\n\nAuf GitHub-gehosteten Runnern sind PowerShell 7 und Pester installiert. Sie können `Install-Module` verwenden, um zusätzliche Abhängigkeiten aus dem PowerShell Gallery zu installieren, bevor Sie Den Code erstellen und testen.\n\n> \\[!NOTE]\n> Vorinstallierte Pakete wie Pester, die von auf GitHub gehosteten Runnern verwendet werden, werden regelmäßig aktualisiert und können zu wichtigen Änderungen führen. Daher wird empfohlen, bei Verwendung von `Install-Module` immer die erforderlichen Paketversionen mit `-MaximumVersion` anzugeben.\n\nSie können auch Abhängigkeiten zwischenspeichern, um Ihren Workflow zu beschleunigen. Weitere Informationen finden Sie unter [Referenz zum Zwischenspeichern von Abhängigkeiten](/de/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\nDer folgende Auftrag installiert z. B. die Module `SqlServer` und `PSScriptAnalyzer`:\n\n```yaml\njobs:\n  install-dependencies:\n    name: Install dependencies\n    runs-on: ubuntu-latest\n    steps:\n      - uses: actions/checkout@v6\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> Standardmäßig stuft PowerShell keine Repositorys als vertrauenswürdig ein. Beim Installieren von Modulen aus dem PowerShell Gallery müssen Sie die Installationsrichtlinie für `PSGallery` explizit auf `Trusted` festlegen.\n\n### Abhängigkeiten „cachen“ (zwischenspeichern)\n\nDu kannst PowerShell-Abhängigkeiten mithilfe eines eindeutigen Schlüssels zwischenspeichern, mit dem du die Abhängigkeiten für zukünftige Workflows mit der [`cache`](https://github.com/marketplace/actions/cache)-Aktion wiederherstellen kannst. Weitere Informationen finden Sie unter [Referenz zum Zwischenspeichern von Abhängigkeiten](/de/actions/using-workflows/caching-dependencies-to-speed-up-workflows).\n\nPowerShell speichert seine Abhängigkeiten je nach Betriebssystem des Runners an unterschiedlichen Speicherorten. Der für ein Windows-Betriebssystem benötigte `path` Speicherort unterscheidet sich beispielsweise von dem, der im folgenden Ubuntu-Beispiel verwendet wird.\n\n```yaml\nsteps:\n  - uses: actions/checkout@v6\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## Testen von Code\n\nDu kannst die gleichen Befehle verwenden, die du auch lokal verwendest, um deinen Code zu bauen und zu testen.\n\n### Linten von Code mit PSScriptAnalyzer\n\nIm folgenden Beispiel wird `PSScriptAnalyzer` installiert und zum Linten aller `ps1`-Dateien im Repository verwendet. Weitere Informationen finden Sie unter [PSScriptAnalyzer auf 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@v6\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## Workflow-Daten als Artefakte paketieren\n\nDu kannst Artefakte hochladen, um sie nach Abschluss eines Workflows anzuzeigen. Zum Beispiel kann es notwendig sein, Logdateien, Core Dumps, Testergebnisse oder Screenshots zu speichern. Weitere Informationen finden Sie unter [Speichern und Freigeben von Daten mit Workflowartefakten](/de/actions/using-workflows/storing-workflow-data-as-artifacts).\n\nIm folgenden Beispiel wird gezeigt, wie die Aktion `upload-artifact` zum Archivieren von Testergebnissen von `Invoke-Pester` verwendet werden kann. Weitere Informationen finden Sie unter der [`upload-artifact` Aktion](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@v6\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@v4\n        with:\n          name: ubuntu-Unit-Tests\n          path: Unit.Tests.xml\n    if: ${{ always() }}\n```\n\nDie `always()`-Funktion konfiguriert den Auftrag, um die Verarbeitung auch dann fortzusetzen, wenn Testfehler auftreten. Weitere Informationen finden Sie unter [Kontextreferenz](/de/actions/learn-github-actions/contexts#always).\n\n## Veröffentlichen auf PowerShell Gallery\n\nSie können Ihren Workflow so konfigurieren, dass Ihr PowerShell-Modul in der PowerShell Gallery veröffentlicht wird, wenn ihre CI-Tests bestehen. Du kannst Geheimnisse verwenden, um Token oder Anmeldeinformationen zu speichern, die zum Veröffentlichen deines Pakets erforderlich sind. Weitere Informationen finden Sie unter [Verwenden von Geheimnissen in GitHub-Aktionen](/de/actions/security-guides/using-secrets-in-github-actions).\n\nIm folgenden Beispiel wird ein Paket erstellt und `Publish-Module` verwendet, um es im PowerShell Gallery zu veröffentlichen:\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@v6\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```"}