Skip to content

⚙️ [Maintenance]: Lock Pester to the 6.x major version#70

Open
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
mainfrom
maintenance/lock-pester-major-6
Open

⚙️ [Maintenance]: Lock Pester to the 6.x major version#70
Marius Storhaug (MariusStorhaug) wants to merge 3 commits into
mainfrom
maintenance/lock-pester-major-6

Conversation

@MariusStorhaug

@MariusStorhaug Marius Storhaug (MariusStorhaug) commented Jul 7, 2026

Copy link
Copy Markdown
Member

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 newest 6.x. Consumers call the action exactly as before; only the resolved Pester major is constrained. Pester 6 keeps the classic Should assertion syntax, so this is low-risk for consumers.

Technical Details

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 AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.ps1 to the NuGet version range [6.0.0,7.0.0).
  • Extend Install-PSResourceWithRetry to accept an optional -Version argument and forward it to Install-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.

Comment thread src/init.ps1
Comment thread src/Helpers.psm1 Outdated
Comment thread README.md
This was referenced Jul 7, 2026
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 AI left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 $pesterModule is still resolved via Get-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 -Version is supplied (e.g. a range like [6.0.0,7.0.0)). Include $Version in 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 thread src/init.ps1
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 thread src/Helpers.psm1
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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants