Skip to content

v5.0.0

Choose a tag to compare

@github-actions github-actions released this 09 Jul 14:08
8a4e652

🌟 [Major]: Version and Prerelease inputs now control Pester (#71)

Invoke-Pester now treats Version and Prerelease as Pester controls. Workflows that previously used those inputs to choose the GitHub PowerShell module used by the init bootstrap step must rename them to GitHubVersion and GitHubPrerelease. Workflows that did not set Version or Prerelease keep installing the latest available Pester by default.

Breaking Changes

Version and Prerelease now apply to Pester, not the GitHub PowerShell module used internally during init.

Before this change, a workflow like this selected the GitHub module version:

- uses: PSModule/Invoke-Pester@vPrevious
  with:
    Version: '1.8.0'
    Prerelease: false

After this change, use the GitHub-prefixed inputs for the bootstrap module:

- uses: PSModule/Invoke-Pester@vNext
  with:
    GitHubVersion: '1.8.0'
    GitHubPrerelease: false

Use Version and Prerelease only when selecting the Pester version that should run the test suite:

- uses: PSModule/Invoke-Pester@vNext
  with:
    Version: '[6.0.0,7.0.0)'
    Prerelease: false

New: Pester version selection per workflow

Version accepts NuGet version syntax, including bare exact versions such as 6.0.0, exact-match ranges such as [6.0.0], and bounded ranges such as [5.0.0,6.0.0). When Version is empty, the action installs the latest available Pester version.

Prerelease controls whether prerelease Pester versions are allowed.

Changed: GitHub bootstrap versioning is GitHub-prefixed

The GitHub PowerShell module used by the init bootstrap step remains configurable, but its inputs are now GitHubVersion and GitHubPrerelease so they do not conflict with the action's Pester-focused inputs.

GitHubVersion also documents NuGet version-range syntax and is passed through to the GitHub-Script action's Version input. A bare version stays exact, matching the NuGet/PSResourceGet behavior described in PSModule/GitHub-Script#97.

Changed: Latest remains the default Pester behavior

Existing consumers can omit Version to keep installing the latest available Pester version. Teams that need a cap or exact version can set it in workflow configuration, while per-repository #Requires declarations remain the safety net that fails tests when the loaded Pester does not satisfy the repository's requirement.

Fixed: The loaded Pester version matches the selected version

The action now imports the exact Pester version resolved from the configured constraint. Version reporting also reflects the loaded module, so workflow logs show the Pester version that actually runs the tests.

Technical Details

  • Changed the public action API so Version and Prerelease are owned by Pester.
  • Moved the GitHub module bootstrap controls to GitHubVersion and GitHubPrerelease, then pass them through to PSModule/GitHub-Script as its Version and Prerelease inputs.
  • Updated init and exec phases to read Pester settings from PSMODULE_INVOKE_PESTER_INPUT_Version and PSMODULE_INVOKE_PESTER_INPUT_Prerelease.
  • Updated Install-PSResourceWithRetry to pass -Version, -Prerelease, and -PassThru to Install-PSResource, resolve the installed/satisfying version, and import it globally with Import-Module -RequiredVersion ... -Global -ErrorAction Stop.
  • Updated init/exec version logging from Get-PSResource to Get-Module so logs report the loaded version rather than the highest installed resource.
  • Hardened the Pester import to fail fast when Version is set but no satisfying installed version can be resolved, instead of silently importing an unconstrained module; the no-Version fallback now imports with -ErrorAction Stop.
  • Added Action-Test coverage for a Pester 5.x range ([5.0.0,6.0.0)) and exact Pester 6.0.0; both constraint jobs pass in CI.
  • This supersedes #70's hardcoded [6.0.0,7.0.0) action-level lock and leaves GUID identity pinning as a later enhancement for #68.