⚙️ [Maintenance]: Lock Pester to the 6.x major version#70
Closed
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Closed
⚙️ [Maintenance]: Lock Pester to the 6.x major version#70Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
Conversation
Install Pester with the version range [6.0.0,7.0.0) so the action always uses the latest 6.x and a future major release cannot be adopted silently. Adds an optional -Version parameter to Install-PSResourceWithRetry.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 7, 2026 14:33
View session
There was a problem hiding this comment.
Pull request overview
This PR aims to prevent unexpected breaking changes by constraining the GitHub Action’s Pester dependency to the 6.x major version, rather than always installing the latest available release.
Changes:
- Pin Pester installation in
src/init.ps1to the NuGet version range[6.0.0,7.0.0). - Extend
Install-PSResourceWithRetryto accept an optional-Versionargument and forward it toInstall-PSResource. - Document the Pester major-version lock in the README.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| src/init.ps1 | Pins Pester to 6.x during init prerequisite installation. |
| src/Helpers.psm1 | Adds optional -Version support to Install-PSResourceWithRetry and uses splatting for install params. |
| README.md | Documents that Pester is locked to the 6.x major version. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
This was referenced Jul 7, 2026
⚙️ [Maintenance]: Lock Pester test dependency to the 6.x major version
PSModule/Template-PSModule#25
Open
Merged
This was referenced Jul 7, 2026
exec.ps1 runs after init.ps1 and re-installed Pester without a version in both the Exec and Eval setup steps, which could pull a newer major and defeat the lock. Install Pester with the same [6.0.0,7.0.0) range used in init.ps1.
Use IsNullOrWhiteSpace so a whitespace-only -Version is not forwarded to Install-PSResource as an invalid version.
Copilot started reviewing on behalf of
Marius Storhaug (MariusStorhaug)
July 7, 2026 22:15
View session
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 4 out of 4 changed files in this pull request and generated 2 comments.
Comments suppressed due to low confidence (3)
src/exec.ps1:16
- This block pins Pester to 6.x, but
$pesterModuleis still resolved viaGet-PSResource, which queries the gallery (latest available) rather than the version actually installed/imported. With the new lock, this can misreport the Pester version being used.
'::group::Exec - Get test kit versions'
$pesterModule = Get-PSResource -Name Pester -Verbose:$false | Sort-Object Version -Descending | Select-Object -First 1
src/exec.ps1:70
- Same issue as earlier: this version-reporting block uses
Get-PSResource(gallery lookup), which can diverge from the actually installed/imported Pester version now that the install is pinned to[6.0.0,7.0.0).
'::group::Eval - Get test kit versions'
$pesterModule = Get-PSResource -Name Pester -Verbose:$false | Sort-Object Version -Descending | Select-Object -First 1
src/Helpers.psm1:1332
- The retry warning omits the version constraint, which makes failures harder to diagnose when
-Versionis supplied (e.g. a range like[6.0.0,7.0.0)). Include$Versionin the warning text (and trim when empty) so logs identify the failing install spec.
} catch {
Write-Warning "Installation of $Name failed with error: $_"
if ($i -eq $RetryCount - 1) {
Comment on lines
+6
to
+7
| # Lock Pester to the 6.x major version so a future major release cannot be adopted silently. | ||
| Install-PSResourceWithRetry -Name 'Pester' -Version '[6.0.0,7.0.0)' |
Comment on lines
+1316
to
+1324
| $installParams = @{ | ||
| Name = $Name | ||
| Repository = 'PSGallery' | ||
| TrustRepository = $true | ||
| WarningAction = 'SilentlyContinue' | ||
| } | ||
| if (-not [string]::IsNullOrWhiteSpace($Version)) { | ||
| $installParams['Version'] = $Version | ||
| } |
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/Confluence
that referenced
this pull request
Jul 7, 2026
Pester tests in this module now require the Pester **6.x** major
version, so every contributor and CI run resolves the same major and a
new Pester major can't slip in and break the suite. The tests previously
declared no framework requirement and ran on whatever Pester happened to
be installed.
## Changed: tests are locked to the Pester 6.x major
Every `*.Tests.ps1` file now starts with a version-bounded requirement:
```powershell
#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '6.0.0'; MaximumVersion = '6.*' }
```
Any Pester `6.x` satisfies it, so minor and patch releases flow in
automatically while moving to a new major stays a deliberate, reviewed
change. No module source or behaviour changes.
## Technical Details
- Prepends a `#Requires -Modules` statement to each test file under
`tests/`; non-test files are untouched.
- `ModuleVersion = '6.0.0'` is the floor and `MaximumVersion = '6.*'`
the wildcard major ceiling. Module-identity (`GUID`) pinning is
intentionally omitted — it is a separate supply-chain control, not part
of the lock-to-major risk appetite.
- The install side is locked to the same major in
PSModule/Invoke-Pester#70. Part of the dependency-management epic
PSModule/Process-PSModule#356.
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/GoogleFonts
that referenced
this pull request
Jul 8, 2026
Pester tests in this module now require the Pester **6.x** major
version, so every contributor and CI run resolves the same major and a
new Pester major can't slip in and break the suite. The tests previously
declared no framework requirement and ran on whatever Pester happened to
be installed.
## Changed: tests are locked to the Pester 6.x major
Every `*.Tests.ps1` file now starts with a version-bounded requirement:
```powershell
#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '6.0.0'; MaximumVersion = '6.*' }
```
Any Pester `6.x` satisfies it, so minor and patch releases flow in
automatically while moving to a new major stays a deliberate, reviewed
change. No module source or behaviour changes.
## Technical Details
- Prepends a `#Requires -Modules` statement to each test file under
`tests/`; non-test files are untouched.
- `ModuleVersion = '6.0.0'` is the floor and `MaximumVersion = '6.*'`
the wildcard major ceiling. Module-identity (`GUID`) pinning is
intentionally omitted — it is a separate supply-chain control, not part
of the lock-to-major risk appetite.
- The install side is locked to the same major in
PSModule/Invoke-Pester#70. Part of the dependency-management epic
PSModule/Process-PSModule#356.
Member
Author
|
Closing this as "Wont do" as we will instead let the versions be controlled via inputs using the Nuget version range syntax. |
Marius Storhaug (MariusStorhaug)
added a commit
to PSModule/NerdFonts
that referenced
this pull request
Jul 9, 2026
#86) This module's Pester tests now lock to the **6.x** major version instead of the exact `5.8.0` pin. An exact pin breaks whenever the runner resolves a different Pester (as happened once 5.8.0 was superseded); a major lock tracks every 6.x release while still blocking an unvetted new major. ## Changed: the exact 5.8.0 pin becomes a 6.x major lock Each `*.Tests.ps1` file now requires: ```powershell #Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '6.0.0'; MaximumVersion = '6.*' } ``` Any Pester `6.x` satisfies it, so routine minor and patch updates no longer need a PR — only a new major does. ## Technical Details - Updates the `#Requires -Modules` statement in each test file under `tests/` from `RequiredVersion = '5.8.0'` to `ModuleVersion = '6.0.0'; MaximumVersion = '6.*'`. - Module-identity (`GUID`) pinning is intentionally omitted — a separate supply-chain control, not part of the lock-to-major risk appetite. - The install side is locked to the same major in PSModule/Invoke-Pester#70. Part of the dependency-management epic PSModule/Process-PSModule#356.
Marius Storhaug (MariusStorhaug)
added a commit
that referenced
this pull request
Jul 9, 2026
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: ```yaml - uses: PSModule/Invoke-Pester@vPrevious with: Version: '1.8.0' Prerelease: false ``` After this change, use the GitHub-prefixed inputs for the bootstrap module: ```yaml - 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: ```yaml - 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. --------- Co-authored-by: Marius Storhaug <Marius.Storhaug@dnb.no>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The action now installs the latest Pester 6.x rather than whatever the newest published Pester is, so a future major release can't be adopted automatically and break every consumer's test run at once.
Changed: Pester is installed locked to the 6.x major
The action resolves Pester with the version range
[6.0.0,7.0.0), always installing the newest6.x. Consumers call the action exactly as before; only the resolved Pester major is constrained. Pester 6 keeps the classicShouldassertion syntax, so this is low-risk for consumers.Technical Details
src/init.ps1installs Pester viaInstall-PSResourceWithRetry -Name 'Pester' -Version '[6.0.0,7.0.0)'; the other modules still install the latest version.src/Helpers.psm1:Install-PSResourceWithRetrygains an optional-Versionparameter passed through toInstall-PSResource— groundwork toward the configurable version input tracked in Install the Pester version requested by the Version input #68.Process-PSModule'sTest-ModuleLocal.ymlso the lock reaches consumers. Part of the dependency-management epic Dependency management for PowerShell scripts and modules Process-PSModule#356.