Fix the failing scheduled Process-PSModule runs on main

[MariusStorhaug]

Context and request

Observed behavior. Every scheduled Process-PSModule run on main fails. The most recent run failed Test-Module and Test-ModuleLocal on Linux, macOS, and Windows, followed by Get-TestResults and Get-CodeCoverage. The framework's own harness aborts during discovery:

[-] Discovery in .../Test-PSModule/.../src/tests/Module/PSModule/PSModule.Tests.ps1 failed with:
System.ArgumentException: Value can not be null or empty array. If this is expected, use
-AllowNullOrEmptyForEach on this It, or set the Run.FailOnNullOrEmptyForEach configuration
option to $false to allow it for the whole run. (Parameter 'ForEach')

The run log shows Pester 6.0.1 loaded. Json has no classes and no enums, so the framework's ForEach collections are empty — which Pester 5 tolerated and Pester 6 rejects by default.

Expected behavior. The scheduled and pull-request runs succeed on all three runners.

Reproduction. Trigger Process-PSModule on main, or wait for the nightly 0 0 * * * schedule.

Environment. .github/workflows/Process-PSModule.yml pinned to PSModule/Process-PSModule@ce64918acc96dda73eb78f827036b794bfa6fa1a # v5.5.7; current release is v6.1.15. tests/Json.Tests.ps1 line 1 pins RequiredVersion = '5.8.0', which no longer matches what the runners install.

Regression. Yes. The last green run was 2026-07-29; failures start 2026-07-30 and have recurred nightly since. The last successful release was v1.2.3 on 2025-10-09.

Workaround. None. main cannot publish while the pipeline is red.

Acceptance criteria.

• A manually dispatched run on main succeeds end to end.
• Test-Module and Test-ModuleLocal pass on Linux, macOS, and Windows.
• Get-CodeCoverage reports at or above the 95% target set in .github/PSModule.yml.
• The nightly scheduled run stays green.

Technical decisions

The root cause is the version pin, not the module's own tests: the failing file is PSModule.Tests.ps1 inside the Test-PSModule action, and v6 of the framework is the release that handles Pester 6. The correction is to adopt the current major, not to patch around the symptom with -AllowNullOrEmptyForEach.

The #Requires line in tests/Json.Tests.ps1 moves to the range the standard specifies rather than another exact pin, so a Pester 6 patch release does not break the build again:

#Requires -Modules @{ ModuleName = 'Pester'; ModuleVersion = '6.0.0'; MaximumVersion = '6.*' }

Both changes ship in one pull request. Bumping the workflow without the test requirement, or the reverse, leaves main red between merges.

PR #23 and PR #26 both cover part of this. Reconcile them into one delivery — #26 is the Dependabot bump to v6.1.14, #23 additionally handles the Pester requirement — and close the redundant one rather than merging both.

Verify against v6.1.15 rather than the v6.1.14 Dependabot proposed, since a newer release exists.

Review the v6 release notes for breaking changes to .github/PSModule.yml settings before merging; the configuration schema may have changed across the major.

Implementation plan

• Reconcile PR ⚙️ [Maintenance]: Adopt Process-PSModule v6.1.4 and require Pester 6.x in tests #23 and PR Bump PSModule/Process-PSModule/.github/workflows/workflow.yml from 5.5.7 to 6.1.14 #26 into a single branch and close the redundant pull request
• Update tests/Json.Tests.ps1 to require Pester >= 6.0.0 and < 7.0.0
• Run the suite locally under Pester 6 and fix any assertion that relied on Pester 5 behaviour
• Bump .github/workflows/Process-PSModule.yml to the v6.1.15 commit SHA with the version tag in a trailing comment
• Check the v6 release notes for .github/PSModule.yml schema changes and adjust the configuration if needed
• Confirm the pull request run is green on all three runners
• Confirm code coverage still meets the 95% target
• After merge, dispatch a run on main and confirm it succeeds