{"meta":{"title":"PowerShell のビルドとテスト","intro":"PowerShell プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成する方法について説明します。","product":"GitHub Actions","breadcrumbs":[{"href":"/ja/enterprise-cloud@latest/actions","title":"GitHub Actions"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials","title":"チュートリアル"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials/build-and-test-code","title":"コードのビルドとテスト"},{"href":"/ja/enterprise-cloud@latest/actions/tutorials/build-and-test-code/powershell","title":"PowerShell"}],"documentType":"article"},"body":"# PowerShell のビルドとテスト\n\nPowerShell プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成する方法について説明します。\n\n## はじめに\n\nこのガイドでは、CIのためのPowerShellの使用方法を示します。 Pester の使用方法、依存関係のインストール方法、モジュールのテスト方法、PowerShell Galleryへの発行方法について説明します。\n\nGitHubホストランナーは、PowerShell及びPesterを含むプリインストールされたソフトウェアを伴うツールキャッシュを持ちます。\n\n最新のソフトウェアと、PowerShell および Pester のプレインストールされたバージョンの完全なリストについては、「[GitHub ホステッド ランナー](/ja/enterprise-cloud@latest/actions/using-github-hosted-runners/about-github-hosted-runners#supported-software)」を参照してください。\n\n## 前提条件\n\nYAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳しくは、「[ワークフローの書き込み](/ja/enterprise-cloud@latest/actions/learn-github-actions)」をご覧ください。\n\nPowerShell及びPesterの基本的な理解をしておくことをおすすめします。 詳細については、次を参照してください。\n\n* [PowerShell の概要](https://docs.microsoft.com/powershell/scripting/learn/ps101/01-getting-started)\n* [Pester](https://pester.dev)\n\n## Pesterのワークフローの追加\n\nPowerShellとPesterでテストを自動化するには、変更がリポジトリにプッシュされるたびに実行されるワークフローを追加できます。 次の例では、`Test-Path` というファイルが存在することを調べるために、`resultsfile.log` が使われます。\n\n次のワークフロー ファイルの例を、リポジトリの `.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@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` - `run` コマンドを実行するときに PowerShell を使うようにジョブを構成します。\n\n* `run: Test-Path resultsfile.log` - リポジトリのルート ディレクトリに `resultsfile.log` というファイルが存在するかどうかをチェックします。\n\n* `Should -Be $true` - Pester を使って期待される結果を定義します。 結果が期待どおりではなかった場合、GitHub Actionsはこれを失敗したテストとしてフラグを立てます。 次に例を示します。\n\n \n\n* `Invoke-Pester Unit.Tests.ps1 -Passthru` - Pester を使って、`Unit.Tests.ps1` というファイルで定義されているテストを実行します。 たとえば、上で説明したのと同じテストを実行するには、`Unit.Tests.ps1` の内容を次のようにします。\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## PowerShellのモジュールの場所\n\n以下の表は、それぞれのGitHubホストランナー内の様々なPowerShellモジュールの場所を示します。\n\n\n\n| | Ubuntu | macOS | Windows |\n| ------------------------- | ------------------------------------------------ | ------------------------------------------------- | ----------------------------------------------------- |\n| **PowerShell システム モジュール** | `/opt/microsoft/powershell/7/Modules/*` | `/usr/local/microsoft/powershell/7/Modules/*` | `C:\\program files\\powershell\\7\\Modules\\*` |\n| **PowerShell アドオン モジュール** | `/usr/local/share/powershell/Modules/*` | `/usr/local/share/powershell/Modules/*` | `C:\\Modules\\*` |\n| **ユーザーがインストールしたモジュール** | `/home/runner/.local/share/powershell/Modules/*` | `/Users/runner/.local/share/powershell/Modules/*` | `C:\\Users\\runneradmin\\Documents\\PowerShell\\Modules\\*` |\n\n
\n\n> \\[!NOTE]\n> Ubuntu ランナーでは、Azure PowerShell モジュールは、PowerShell アドオン モジュールの既定の場所 (つまり、`/usr/share/`) ではなく、`/usr/local/share/powershell/Modules/` に格納されます。\n\n## 依存関係のインストール\n\nGitHubホストランナーには、PowerShell 7とPesterがインストールされています。\n`Install-Module` を使用して、コードをビルドしてテストする前に、PowerShell Galleryから追加の依存関係をインストールできます。\n\n> \\[!NOTE]\n> GitHub ホステッド ランナーによって使用されるプレインストールされたパッケージ (Pester など) は定期的に更新され、重要な変更が行われることがあります。 そのため、`Install-Module` で `-MaximumVersion` を使って必要なパッケージのバージョンを常に指定することをお勧めします。\n\nワークフローの速度を上げるために、依存関係をキャッシュすることもできます。 詳しくは、「[依存関係キャッシュのリファレンス](/ja/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。\n\nたとえば、次のジョブでは、`SqlServer` モジュールと `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> 既定では、PowerShell によって信頼されるリポジトリはありません。 PowerShell Galleryからモジュールをインストールする場合は、`PSGallery` のインストール ポリシーを `Trusted` に明示的に設定する必要があります。\n\n### 依存関係のキャッシング\n\n一意のキーを使って PowerShell の依存関係をキャッシュすることができ、これにより将来のワークフローで [`cache`](https://github.com/marketplace/actions/cache) アクションによってその依存関係を復元できます。 詳しくは、「[依存関係キャッシュのリファレンス](/ja/enterprise-cloud@latest/actions/using-workflows/caching-dependencies-to-speed-up-workflows)」をご覧ください。\n\nPowerShellは、ランナーのオペレーティングシステムによって依存関係を様々な場所にキャッシュします。 たとえば、次の Ubuntu の例で使用する `path` の場所は、Windows オペレーティング システムでは異なります。\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## コードのテスト\n\nローカルで使うのと同じコマンドを、コードのビルドとテストに使えます。\n\n### PSScriptAnalyzerを使ったコードの文法チェック\n\n次の例では、`PSScriptAnalyzer` がインストールされ、それを使ってリポジトリ内のすべての `ps1` ファイルがリントされます。 詳細については、GitHub の「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## 成果物としてのワークフローのデータのパッケージ化\n\nワークフローの完了後に、成果物をアップロードして見ることができます。 たとえば、ログファイル、コアダンプ、テスト結果、スクリーンショットを保存する必要があるかもしれません。 詳しくは、「[ワークフロー成果物を使ったデータの格納と共有](/ja/enterprise-cloud@latest/actions/using-workflows/storing-workflow-data-as-artifacts)」をご覧ください。\n\n次の例では、`upload-artifact` アクションを使って、`Invoke-Pester` から受け取ったテスト結果をアーカイブする方法を示します。 詳細については、「[`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@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\n```\n `always()` 関数では、テストにエラーがあっても処理を続行するようにジョブが構成されます。 詳しくは、「[AUTOTITLE](/actions/learn-github-actions/contexts#always)」をご覧ください。\n```\n\n## PowerShell Galleryへの公開\n\nCI テストに合格したときに PowerShell モジュールをPowerShell Galleryに発行するようにワークフローを構成できます。 パッケージを公開するのに必要なトークンや認証情報を保存するために、シークレットを使うことができます。 詳しくは、「[GitHub Actions でのシークレットの使用](/ja/enterprise-cloud@latest/actions/security-guides/using-secrets-in-github-actions)」をご覧ください。\n\n次の例では、パッケージを作成し、`Publish-Module` を使用して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@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```"}