v5.0.0
🌟 [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.
- Related to #68
- Aligns with PSModule/GitHub-Script#97 for NuGet version-range syntax
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: falseAfter this change, use the GitHub-prefixed inputs for the bootstrap module:
- uses: PSModule/Invoke-Pester@vNext
with:
GitHubVersion: '1.8.0'
GitHubPrerelease: falseUse 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: falseNew: 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
VersionandPrereleaseare owned by Pester. - Moved the GitHub module bootstrap controls to
GitHubVersionandGitHubPrerelease, then pass them through toPSModule/GitHub-Scriptas itsVersionandPrereleaseinputs. - Updated init and exec phases to read Pester settings from
PSMODULE_INVOKE_PESTER_INPUT_VersionandPSMODULE_INVOKE_PESTER_INPUT_Prerelease. - Updated
Install-PSResourceWithRetryto pass-Version,-Prerelease, and-PassThrutoInstall-PSResource, resolve the installed/satisfying version, and import it globally withImport-Module -RequiredVersion ... -Global -ErrorAction Stop. - Updated init/exec version logging from
Get-PSResourcetoGet-Moduleso logs report the loaded version rather than the highest installed resource. - Hardened the Pester import to fail fast when
Versionis set but no satisfying installed version can be resolved, instead of silently importing an unconstrained module; the no-Versionfallback now imports with-ErrorAction Stop. - Added Action-Test coverage for a Pester 5.x range (
[5.0.0,6.0.0)) and exact Pester6.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.