Pipeline stages#

The Process-PSModule workflow composes its work from a set of reusable jobs. Each one is described below, in the order it runs, with a link to the workflow that implements it.

For which of these jobs run in a given trigger scenario, see the scenario matrix.

Plan#

workflow

The Plan job is the single decision point of the workflow. It reads the settings file (.github/PSModule.yml), collects event context from GitHub, and decides what should happen in the rest of the process. Using that situational awareness, it calculates the next module version.

The user-facing settings file stays in .github/PSModule.yml. The workflow enriches that input into an internal runtime Settings object passed between jobs. In this runtime contract, execution decisions are phase-owned (*.Enabled), test suite matrices are computed under each owning test phase, and resolved version metadata is stored under Settings.Publish.Module.Resolution. The *.Suites values are workflow outputs, not authorable layout settings.

Internal runtime settings contract#

Lint-Repository#

workflow

Build module#

workflow

• Compiles the module source code into a PowerShell module, stamping the version from Settings.Publish.Module.Resolution.Version into the manifest.
• Uploads the built artifact.

Test source code#

workflow

• Tests the source code in parallel (matrix) using:
• PSModule framework settings for style and standards for source code
• This produces a JSON-based report that is used by Get-PesterTestResults evaluate the results of the tests.

For the coding practices this step enforces, see framework test IDs.

Lint source code#

workflow

• Lints the source code in parallel (matrix) using:
• PSScriptAnalyzer rules
• This produces a JSON-based report that is used by Get-PesterTestResults evaluate the results of the linter.

Framework test#

workflow

• Tests and lints the module in parallel (matrix) using:
• PSModule framework settings for style and standards for modules
• PSScriptAnalyzer rules
• This produces a JSON-based report that is used by Get-PesterTestResults evaluate the results of the tests.
• Code coverage for framework-generated code: This step collects code coverage for framework-generated boilerplate. During the build step, Build-PSModule injects boilerplate code into the compiled .psm1 file — including type accelerator registration for public classes and enums, and the OnRemove cleanup hook. The framework tests in Test-PSModule exercise these code paths and produce coverage artifacts that are aggregated with coverage from Test-ModuleLocal in the Get code coverage step. This keeps framework-generated lines from counting against the module author's coverage report.

For the checks this step enforces on the built module, see framework test IDs.

Test module#

workflow

• Imports and tests the module in parallel (matrix) using module-local Pester tests.
• Discovers module-local tests recursively under tests/, applying a per-directory precedence independently at every level.
• Supports two special workflow phase scripts executed via separate dedicated jobs:
• tests/BeforeAll.ps1: Runs once before all module-local test matrix jobs to set up the test environment.
• tests/AfterAll.ps1: Runs once after all module-local test matrix jobs complete to clean up the test environment.
• The workflow checks only those exact repository-root paths; phase detection is non-recursive.
• This produces a JSON-based report that is used by Get-PesterTestResults to evaluate the results of the tests.

How to write these tests, including the Pester version requirement and shared-infrastructure patterns, is covered in Writing module tests.

Get test results#

workflow

• Gathers the test results from the previous steps and creates a summary of the results.
• If any tests have failed, the workflow will fail here.

Get code coverage#

workflow

• Gathers the code coverage from the previous steps and creates a summary of the results.
• Aggregates coverage from the Framework test step (framework-generated boilerplate) and the Test module step (module author code). A command executed in either step counts as covered, so framework-generated lines do not count against the module author's coverage target.
• If the code coverage is below the target, the workflow will fail here.

Publish module#

workflow

• Publishes the artifact to the PowerShell Gallery exactly as built — no version mutation.
• Creates a GitHub Release using the version already stamped in the manifest.
• Attaches the built module as a .zip asset on the GitHub Release so consumers can download the exact bytes that were tested and pushed to the PowerShell Gallery.
• Abandoned PR cleanup: When a PR is closed without merging (abandoned), the workflow automatically cleans up any prerelease versions and tags that were created for that PR. This ensures that abandoned work doesn't leave orphaned prereleases in the PowerShell Gallery or repository. This behavior is controlled by the Publish.Module.AutoCleanup setting.

Build docs#

workflow

• Generates documentation and lints the documentation using:
• super-linter.

Build site#

workflow

• Generates a static site using:
• Zensical.
• Uses zensical.toml as the site configuration contract.

Publish Docs#

workflow