ja ドキュメントには頻繁に更新が加えられ、その都度公開されています。本ページの翻訳はまだ未完成な部分があることをご了承ください。最新の情報については、英語のドキュメンテーションをご参照ください。本ページの翻訳に問題がある場合はこちらまでご連絡ください。

PowerShell のビルドとテスト

PowerShell プロジェクトのビルドとテストのための継続的インテグレーション (CI) ワークフローを作成できます。

GitHub ActionsはGitHub Free、GitHub Pro、GitHub FreeのOrganization、GitHub Team、GitHub Enterprise Cloud、GitHub Oneで利用できます。 GitHub Actionsは、レガシーのリポジトリごとのプランを使っているアカウントが所有しているプライベートリポジトリでは利用できません。


注釈: GitHub Enterprise Server 2.22 での GitHub Actions サポートは、限定パブリックベータです。 To review the external storage requirements and request access to the beta, see "Getting started with GitHub Actions for GitHub Enterprise Server."

Note: GitHub-hosted runners are not currently supported on GitHub Enterprise Server. You can see more information about planned future support on the GitHub public roadmap.


このガイドでは、CIのためのPowerShellの使用方法を示します。 Pesterの使い方、依存関係のインストール、モジュールのテスト、PowerShell Galleryへの公開について説明します。

GitHubホストランナーは、PowerShell及びPesterを含むプリインストールされたソフトウェアを伴うツールキャッシュを持ちます。 最新のソフトウェアと、PowerShellおよびPesterのプリインストールされたバージョンの完全なリストについては、「GitHub ホストランナーの仕様」を参照してください。


YAMLとGitHub Actionsの構文に馴染んでいる必要があります。 詳しい情報については、「GitHub Actions を学ぶ」を参照してください。

PowerShell及びPesterの基本的な理解をしておくことをおすすめします。 詳しい情報については、以下を参照してください。

Using self-hosted runners on GitHub Enterprise Server

When using setup actions (such as actions/setup-LANGUAGE) on GitHub Enterprise Server with self-hosted runners, you might need to set up the tools cache on runners that do not have internet access. For more information, see "Setting up the tool cache on self-hosted runners without internet access."


PowerShellとPesterでテストを自動化するには、変更がリポジトリにプッシュされるたびに実行されるワークフローを追加できます。 以下の例では、resultsfile.logというファイルがあるかをチェックするためにTest-Pathが使われます。


name: Test PowerShell on Ubuntu
on: push

    name: Pester test
    runs-on: ubuntu-latest
    - name: Check out repository code
      uses: actions/checkout@v2
    - name: Perform a Pester test from the command-line
      shell: pwsh
      run: Test-Path resultsfile.log | Should -Be $true
    - name: Perform a Pester test from the Tests.ps1 file
      shell: pwsh
      run: |
        Invoke-Pester Unit.Tests.ps1 -Passthru
  • shell: pwsh - Configures the job to use PowerShell when running the run commands.

  • run: Test-Path resultsfile.log - Check whether a file called resultsfile.log is present in the repository's root directory.

  • Should -Be $true - Uses Pester to define an expected result. If the result is unexpected, then GitHub Actions flags this as a failed test. 例:

    Failed Pester test

  • Invoke-Pester Unit.Tests.ps1 -Passthru - Uses Pester to execute tests defined in a file called Unit.Tests.ps1. For example, to perform the same test described above, the Unit.Tests.ps1 will contain the following:
    Describe "Check results file is present" {
        It "Check results file is present" {
            Test-Path resultsfile.log | Should -Be $true

PowerShell module locations

The table below describes the locations for various PowerShell modules in each GitHub-hosted runner.

PowerShell system modules/opt/microsoft/powershell/7/Modules/*/usr/local/microsoft/powershell/7/Modules/*C:\program files\powershell\7\Modules\*
PowerShell add-on modules/usr/local/share/powershell/Modules/*/usr/local/share/powershell/Modules/*C:\Modules\*
User-installed modules/home/runner/.local/share/powershell/Modules/*/Users/runner/.local/share/powershell/Modules/*C:\Users\runneradmin\Documents\PowerShell\Modules\*


GitHub-hosted runners have PowerShell 7 and Pester installed. You can use Install-Module to install additional dependencies from the PowerShell Gallery before building and testing your code.

Note: The pre-installed packages (such as Pester) used by GitHub-hosted runners are regularly updated, and can introduce significant changes. As a result, it is recommended that you always specify the required package versions by using Install-Module with -MaximumVersion.

When using GitHub-hosted runners, you can also cache dependencies to speed up your workflow. 詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

For example, the following job installs the SqlServer and PSScriptAnalyzer modules:

    name: Install dependencies
    runs-on: ubuntu-latest
    - uses: actions/checkout@v2
    - name: Install from PSGallery
      shell: pwsh
      run: |
        Set-PSRepository PSGallery -InstallationPolicy Trusted
        Install-Module SqlServer, PSScriptAnalyzer

Note: By default, no repositories are trusted by PowerShell. When installing modules from the PowerShell Gallery, you must explicitly set the installation policy for PSGallery to Trusted.


When using GitHub-hosted runners, you can cache PowerShell dependencies using a unique key, which allows you to restore the dependencies for future workflows with the cache action. 詳しい情報については、「ワークフローを高速化するための依存関係のキャッシュ」を参照してください。

PowerShell caches its dependencies in different locations, depending on the runner's operating system. For example, the path location used in the following Ubuntu example will be different for a Windows operating system.

  - uses: actions/checkout@v2
  - name: Setup PowerShell module cache
    id: cacher
    uses: actions/cache@v2
      path: "~/.local/share/powershell/Modules"
      key: ${{ runner.os }}-SqlServer-PSScriptAnalyzer
  - name: Install required PowerShell modules
    if: steps.cacher.outputs.cache-hit != 'true'
    shell: pwsh
    run: |
      Set-PSRepository PSGallery -InstallationPolicy Trusted
      Install-Module SqlServer, PSScriptAnalyzer -ErrorAction Stop



Using PSScriptAnalyzer to lint code

The following example installs PSScriptAnalyzer and uses it to lint all ps1 files in the repository. For more information, see PSScriptAnalyzer on GitHub.

    name: Install and run PSScriptAnalyzer
    runs-on: ubuntu-latest
    - uses: actions/checkout@v2
    - name: Install PSScriptAnalyzer module
      shell: pwsh
      run: |
            Set-PSRepository PSGallery -InstallationPolicy Trusted
            Install-Module PSScriptAnalyzer -ErrorAction Stop
    - name: Lint with PSScriptAnalyzer
      shell: pwsh
      run: |
            Invoke-ScriptAnalyzer -Path *.ps1 -Recurse -Outvariable issues
            $errors   = $issues.Where({$_.Severity -eq 'Error'})
            $warnings = $issues.Where({$_.Severity -eq 'Warning'})
            if ($errors) {
                Write-Error "There were $($errors.Count) errors and $($warnings.Count) warnings total." -ErrorAction Stop
            } else {
                Write-Output "There were $($errors.Count) errors and $($warnings.Count) warnings total."


ワークフローの完了後に、成果物をアップロードして見ることができます。 たとえば、ログファイル、コアダンプ、テスト結果、スクリーンショットを保存する必要があるかもしれません。 詳しい情報については「成果物を利用してワークフローのデータを永続化する」を参照してください。

The following example demonstrates how you can use the upload-artifact action to archive the test results received from Invoke-Pester. 詳しい情報についてはupload-artifactアクションを参照してください。

name: Upload artifact from Ubuntu

on: [push]

    name: Run Pester and upload results
    runs-on: ubuntu-latest
    - uses: actions/checkout@v2
    - name: Test with Pester
      shell: pwsh
      run: Invoke-Pester Unit.Tests.ps1 -Passthru | Export-CliXml -Path Unit.Tests.xml
    - name: Upload test results
      uses: actions/upload-artifact@v2
        name: ubuntu-Unit-Tests
        path: Unit.Tests.xml
    if: ${{ always() }}

The always() function configures the job to continue processing even if there are test failures. For more information, see "always."

You can configure your workflow to publish your PowerShell module to the PowerShell Gallery when your CI tests pass. You can use secrets to store any tokens or credentials needed to publish your package. 詳しい情報については、「暗号化されたシークレットの作成と利用」を参照してください。

The following example creates a package and uses Publish-Module to publish it to the PowerShell Gallery:

name: Publish PowerShell Module

    types: [created]

    runs-on: ubuntu-latest
    - uses: actions/checkout@v2
    - name: Build and publish
        NUGET_KEY: ${{ secrets.NUGET_KEY }}
      shell: pwsh
      run: |
        ./build.ps1 -Path /tmp/samplemodule
        Publish-Module -Path /tmp/samplemodule -NuGetApiKey $env:NUGET_KEY -Verbose

Did this doc help you?

Privacy policy

Help us make these docs great!

All GitHub docs are open source. See something that's wrong or unclear? Submit a pull request.

Make a contribution

OR, learn how to contribute.