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

🪲 [Fix]: Obsolete GitHub token write permissions removed (#521)

Repositories that use the GitHub App permission model can run Process-PSModule without granting unneeded repository, pull-request, or status write access. GitHub Pages deployments continue to use the caller's github.token with contents: read, pages: write, and id-token: write.

Fixed: Reusable workflow permission escalation

The reusable workflow no longer requests permissions that GitHub App installation tokens already provide for release and pull-request operations. Update caller workflows to use the narrowed permission block documented for v8.

permissions:
  contents: read
  pages: write
  id-token: write

Bump the github-actions group with 2 updates (#511)

Bumps the github-actions group with 2 updates: actions/checkout and actions/setup-python.

Updates actions/checkout from 7.0.0 to 7.0.1

Updates actions/setup-python from 6.3.0 to 7.0.0

🌟 [Major]: Publish stable releases from default-branch pushes (#512)

Process-PSModule now authorizes stable module publication from an important push to the default branch rather than from a merged pull_request event. An associated merged pull request supplies labels and release notes only when its merge commit exactly matches the pushed SHA; direct pushes and default-branch manual dispatches release a Patch version with commit-based notes.

Breaking Changes

Caller workflows must add a push trigger for their default branch to receive stable releases. The canonical caller templates now use non-cancelling per-pull-request-or-ref concurrency so pull-request cleanup and the resulting default-branch release remain independent while all release mutations queue safely. The consumer-repository rollout remains tracked in #438.

Changed: Stable release lifecycle

• Open labelled pull requests can publish prereleases; closed pull requests run prerelease cleanup only.
• Important default-branch pushes run the full pipeline and publish a stable release only after PowerShell Gallery publication succeeds.
• GitHub releases and tags target the exact tested pushed commit.
• Direct default-branch pushes and manual dispatches default to Patch regardless of AutoPatching; pull-request prereleases retain their configured AutoPatching behavior.
• First pushes are evaluated from the complete Git tree, and truncated trees fail explicitly rather than producing an unsafe release decision.
• Only a real pull_request.closed event can enter cleanup; a label change on an already closed PR runs no build, prerelease, or cleanup path.
• Release workflow concurrency uses cancel-in-progress: false to preserve serialized artifact and tag mutation.

Dogfood and documentation

• The default and manifest dogfood callers now receive the complete PR event contract, including label changes and closure, and do not cancel release-capable runs.
• Fixture roots are important, fixture sites build, and Publish.Site.Skip prevents deployment to the Process-PSModule Pages environment.
• Caller, first-release, scenario, stage, settings, specification, and module-standard documentation now define default-branch push authority, cleanup-only closed PRs, direct-push behavior, and non-cancelling concurrency.

Scope boundary

Release-GHRepository@v2.0.3, which releases Process-PSModule itself, only supports pull-request event payloads. This PR therefore does not install a push trigger that would succeed without producing that repository release. Push-capable repository releases and moving workflow-consumer tags are tracked separately in PSModule/Release-GHRepository#108.

Technical Details

• The Plan settings action normalizes PR, push, and manual-dispatch state into a shared context.
• Push-to-PR association uses GET /repos/{owner}/{repo}/commits/{sha}/pulls and requires an exact merged commit match on the default branch.
• Version-label conflicts remain blocking for release decisions but cannot block closed-PR cleanup.
• Publishing, GitHub release creation, and cleanup receive the normalized PR context explicitly, so direct releases never attempt PR comments.
• Publish.Site.Skip separates site build from deployment; dogfood callers mark their fixture roots as important, build site artifacts, and skip real Pages publication.

🌟 [Major]: Reusable workflows now use GitHub App orchestration and explicit publish credentials (#408)

Process-PSModule now performs repository inspection, versioning, release management, and pull-request feedback through a configured GitHub App. Publishing uses the explicit PSGALLERY_API_KEY credential consistently from the reusable workflow through the publishing action.

Breaking Changes

Caller workflows must now pass GitHub App credentials and the PowerShell Gallery credential through the reusable workflow contract. Workflows that omit these required secrets fail before their dependent stages run.

secrets:
  PSGALLERY_API_KEY: ${{ secrets.PSGALLERY_API_KEY }}
  GitHubAppClientId: ${{ secrets.GITHUB_APP_CLIENT_ID }}
  GitHubAppPrivateKey: ${{ secrets.GITHUB_APP_PRIVATE_KEY }}

The caller can retain any local GitHub App secret names; only the reusable-workflow boundary names are fixed. PSGALLERY_API_KEY is also the input name of the publishing action.

Changed: Scoped GitHub automation

Every GitHub-dependent stage now mints a short-lived token for the triggering repository and requests only the access it needs. Version planning reads repository and pull-request data, builds read repository metadata, and publishing creates releases, uploads assets, cleans prereleases, and posts pull-request comments through the configured App.

The GitHub App installation needs Contents: write and Pull requests: write. Metadata: read is granted automatically. Permissions such as Actions, Statuses, Pages, and ID tokens remain part of the caller workflow's default github.token path and are not App permissions.

Technical Details

• Plan, Build-Module, and Publish-Module mint repository-scoped installation tokens with pinned actions/create-github-app-token.
• GitHub-facing actions receive the token only through step-scoped GH_TOKEN; the GitHub App path has no github.token fallback.
• The release path, version resolution, repository metadata reads, settings, comments, and prerelease cleanup all use the App token.
• The reusable workflow, publishing action input, action environment variable, and Process-PSModule documentation use PSGALLERY_API_KEY.
• Canonical caller templates and Process-PSModule documentation include the App credential contract, PowerShell Gallery credential, permission matrix, and Dependabot configuration requirement.
• The GitHub-Script named-token-input hardening follow-up remains tracked separately.

⚙️ [Maintenance]: Publish and release execution paths are now decoupled (#407)

PowerShell Gallery publishing and GitHub Release creation now run as independent publish-pipeline responsibilities, so each operation reports its own outcome and a partial release can be safely retried.

Changed: Publishing and release operations are separate

Publish-PSModule now publishes the tested module artifact to PowerShell Gallery only. GitHub release creation, release notes, and release-asset upload run through the dedicated Release-PSModule action.

Technical Details

• The Plan job remains the single version authority: Publish.Module.Resolution.FullVersion is passed directly to Release-PSModule as the GitHub release tag.
• Release-PSModule detects an existing tag, resumes the module ZIP upload, and exports the final tag and release URL as action outputs.
• Gallery and release steps have independent failure behavior; cleanup only runs after a successful stable release, while abandoned-PR cleanup remains supported.
• Cleanup receives the release tag through the release action's declared output rather than shared environment state.
• The reusable workflow now uses job-scoped write permissions and a pinned Ubuntu runner; both publishing actions have action-local READMEs.
• Pester covers prefixed prerelease WhatIf behavior and resuming an existing release without recreating it. Full live publishing remains intentionally out of scope.

Add generic missed-path coverage reporting (#421)

Summary

Adds missed-path reporting to the upstream Process-PSModule coverage flow so consumer repositories do not need repo-local post-coverage jobs.

Changes

• Extended .github/actions/Get-PesterCodeCoverage to generate a generic missed-path report from merged coverage data.
• Added a Missed paths section to the code coverage step summary.
• Emit CodeCoverage-MissedPaths.md and CodeCoverage-MissedPaths.json under CodeCoverage-MissedPaths/.
• Upload CodeCoverage-MissedPaths as an artifact in .github/workflows/Get-CodeCoverage.yml.

Notes

• The implementation intentionally avoids repo-specific heuristics and groups misses by file path and missed line coverage.
• Artifact upload runs with if: always() so the report is still available when coverage threshold enforcement fails.

⚙️ [Maintenance]: GitHub Actions checkouts use least-privilege settings (#412)

GitHub Actions workflows now use the pinned actions/checkout v7.0.1 release consistently, avoid unnecessary full-history downloads, and prevent checkout credentials from persisting in the workspace. Generated documentation is linted with Super-Linter using filesystem discovery restricted to Markdown files.

Changed: Workflow checkout security and efficiency

All checkout steps disable credential persistence because these workflows do not rely on the checkout repository for authenticated Git operations. Super-Linter uses filesystem discovery instead of Git, so full-history fetching is not required.

Changed: Generated documentation lint scope

The documentation build runs Super-Linter in local mode with filesystem discovery and limits the include pattern to generated .md and .markdown files. The default branch is not configured, avoiding Git branch comparison and keeping the lint focused on the documentation output.

🪲 [Fix]: Wildcard maximum versions no longer fail module processing (#446)

Module requirements can now use wildcard maximum versions such as 1.* without module builds or installations failing. Versions remain constrained to the requested major or minor release line, while concrete maximum versions keep their existing behavior.

Fixed: wildcard maximum versions no longer fail module builds

Module manifests can now preserve wildcard maximum-version requirements instead of rejecting them as invalid version values. A requirement such as MaximumVersion = '1.*' remains usable during manifest generation.

Fixed: wildcard maximum versions resolve to the correct release range

Module installation translates wildcard maximum versions into an exclusive upper bound. For example, MinimumVersion = '1.0.0' and MaximumVersion = '1.*' resolve to the range [1.0.0,2.0.0), allowing 1.x releases without admitting 2.x releases. Unsupported wildcard patterns are reported clearly.

🪲 [Fix]: Release tags keep the configured version prefix (#440)

Releases created by the module pipeline are tagged with the version prefix configured in .github/PSModule.yml again. A repository that keeps the default VersionPrefix: 'v' is tagged v1.1.10, not 1.1.10, and its prereleases are tagged v1.1.11-mybranch001. A repository that sets VersionPrefix: '' keeps its unprefixed tags exactly as before.

Fixed: release tags no longer lose the configured version prefix

Since v6 the release tag was built from the compiled manifest's ModuleVersion alone. That value is Major.Minor.Patch by definition, so the prefix had nowhere to live and every repository publishing on v6 with the default prefix picked up a tag that did not match its own history — PSModule/Toml went from v0.0.1 to 0.0.2, PSModule/Domeneshop from v0.0.2 to 1.0.0, PSModule/PSSemVer from v1.1.9 to 1.1.10.

Nothing needs to change in a module repository. The prefix is read from the setting that already exists:

Publish:
  Module:
    VersionPrefix: 'v'   # default; set to '' for unprefixed tags

The prefix applies to the GitHub release tag and to nothing else. A PowerShell module manifest's ModuleVersion and a PowerShell Gallery package version only accept plain SemVer, so the version published to the Gallery, the version in the Gallery link, and the name of the module zip attached to the release all stay unprefixed. With VersionPrefix: 'v' a release looks like this:

Repositories that already published an unprefixed tag on v6 keep it. Those releases are public, their artifacts are linked from the release pages, and the PowerShell Gallery listing points at them, so they are left alone and the prefix resumes from the next release. An unprefixed tag left in the history does not affect future version resolution.

Module name:    [PSModuleTest]
Version prefix: [v]
WhatIf:         [True]

ModuleVersion    : 6.1.16
VersionPrefix    : v
Prerelease       : fixversionprefixreleasetag001
CreatePrerelease : True
ReleaseTag       : v6.1.16-fixversionprefixreleasetag001

WhatIf: gh release create v6.1.16-fixversionprefixreleasetag001 --title v6.1.16-fixversionprefixreleasetag001 --notes-file /tmp/tmpjar7Eu.tmp --target fix-version-prefix-release-tag --prerelease

Publishing complete. PowerShell Gallery version: [1.1.10]. GitHub release tag: [v1.1.10].
gh pr comment 42 -b '✅ New release: PowerShell Gallery - [PSModuleTest 1.1.10](https://www.powershellgallery.com/packages/PSModuleTest/1.1.10)'