Skip to content

v8.0.3

Latest

Choose a tag to compare

@github-actions github-actions released this 15 Aug 18:35
· 2 commits to main since this release
16419d0

Upgrade Process-PSModule to Pester 6.1 (#519)

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