Upgrade Process-PSModule to Pester 6.1

[Marius Storhaug (MariusStorhaug)]

Implemented in Process-PSModule

• Enforce the Pester [6.1.0,7.0.0) range in reusable framework test runs.
• Align module-local workflow inputs with the current Invoke-Pester contract: Version/Prerelease select Pester, while GitHubVersion/GitHubPrerelease select the GitHub module. Pester prerelease remains at the action default.
• Keep the six Test-PSModule container/test files inside the action implementation at .github/actions/Test-PSModule/src/tests, because they are context-dependent framework suites executed against the compiled module or source tree. Discovery remains $PSScriptRoot/tests/$settings.
• Add a framework CI contract test that validates Pester 6.1 configuration properties:
  • Run.Shuffle
  • Run.ShuffleSeed
  • Run.Parallel
  • Run.ParallelThrottleLimit
  • Debug.ShowStartMarkers
• Align coverage input documentation with Pester 6.1: supported formats are JaCoCo and Cobertura, and profiler-based tracing is documented correctly.
• Update Pester 6.1 authoring and coverage-report guidance.

Pester 6.1 runtime audit

A local Pester 6.1 probe generated a passing test result and coverage report, and the Get-PesterCodeCoverage action processed that JSON successfully. The coverage result shape remains compatible: CoveragePercent, CoveragePercentTarget, CommandsMissed, CommandsExecuted, FilesAnalyzed, and all count properties are present and consumed correctly.

The Pester result still exposes Containers; each container retains Data, Blocks, and aggregate result/count properties. The existing container files therefore remain compatible with the compiled-module/source-tree execution model.

Contract findings and required upstream follow-up

The current PSModule/Invoke-Pester v5.1.0 action does not expose these Pester configuration properties as action inputs, so this repository deliberately does not add incompatible passthrough mappings:

• Run_Shuffle
• Run_ShuffleSeed
• Run_Parallel
• Run_ParallelThrottleLimit
• Debug_ShowStartMarkers

The coordinated PSModule/Invoke-Pester follow-up must add each input to action.yml, forward each PSMODULE_INVOKE_PESTER_INPUT_* environment variable, map them into the generated PesterConfiguration, and publish a version/tag that Process-PSModule can pin. Process-PSModule can then expose the corresponding reusable-action inputs and pass them through.

Test and fixture boundaries confirmed

• Module-local tests assume the built module is already loaded: Test-ModuleLocal.yml imports the artifact in its prescript before invoking Pester.
• Framework module tests import the module explicitly in their own test scopes; no implicit preload was introduced.
• PSD1 files in the repository test fixture (src/data/Config.psd1 and src/data/Settings.psd1) are not implicitly loaded and are currently unused. Any future PSD1 dataset test must call Import-PowerShellDataFile explicitly or load it from supported setup.
• Expose-TestData passes only explicit caller-provided fixtures as environment variables to setup, teardown, and tests.
• Module linting remains a separate Invoke-ScriptAnalyzer job and artifact path; it is not folded into Pester execution.

Validation

• Pester 6.1 configuration contract validated locally.
• Pester 6.1 result/container and coverage shapes inspected locally.
• Get-PesterCodeCoverage executed against a generated Pester 6.1 coverage JSON fixture and passed.
• Restored Test-PSModule scripts parsed successfully.
• Test-PSModule path resolution validated from a consumer repository root.
• Changed PowerShell parsed successfully.
• git diff --check passed.

Commits: 337533c, ad2961e, 8c3366f, 0423d6a

[github-actions]

Super-linter summary

Language	Validation result
CHECKOV	Pass ✅
CSS	Pass ✅
CSS_PRETTIER	Pass ✅
GITHUB_ACTIONS	Pass ✅
GITHUB_ACTIONS_ZIZMOR	Pass ✅
GITLEAKS	Pass ✅
GIT_MERGE_CONFLICT_MARKERS	Pass ✅
HTML	Pass ✅
JAVASCRIPT_ES	Pass ✅
JAVASCRIPT_PRETTIER	Pass ✅
MARKDOWN	Pass ✅
NATURAL_LANGUAGE	Pass ✅
POWERSHELL	Pass ✅
PRE_COMMIT	Pass ✅
SPELL_CODESPELL	Pass ✅
TRIVY	Pass ✅
YAML	Pass ✅

All files and directories linted successfully

For more information, see the GitHub Actions workflow run

Powered by Super-linter