v6.1.12

🩹 [Patch]: Prerelease cleanup no longer depends on module artifact (#400)

Prerelease cleanup now runs as an independent workflow action, so publish logic and cleanup logic can execute in the right scenarios without being coupled to module artifact download.

Changed: Publish and cleanup are now separate actions

Publish-PSModule now only performs artifact download and publish/release work, while cleanup moved into a dedicated Cleanup-PSModulePrereleases action.

Fixed: No-build cleanup paths no longer depend on publish action internals

Publish-Module.yml now runs publish only when ReleaseType != 'None', and runs cleanup independently when ReleaseType != 'Prerelease' with existing AutoCleanup and WhatIf controls.

Technical Details

• Removed cleanup inputs and cleanup step from .github/actions/Publish-PSModule/action.yml.
• Added .github/actions/Cleanup-PSModulePrereleases/ with its own composite action and cleanup script.
• Updated .github/workflows/Publish-Module.yml to call the two actions as separate, scenario-gated steps.
• Preserved release-tag exclusion by passing PSMODULE_PUBLISH_PSMODULE_CONTEXT_ReleaseTag into the cleanup action when publish ran earlier in the job.
• Implementation plan progress: completed the decoupling requested in issue #376 by separating cleanup from publish artifact flow.

Related issues

• Fixes #376

v6.1.11

⚙️ [Maintenance]: Internalize runtime settings by phase (#402)

Runtime execution flags and test matrices are now owned by each phase object instead of a shared root Run/TestSuites contract.

Changed: Runtime execution state is phase-owned

Get-PSModuleSettings now enriches each phase with Desired/Enabled state and stores suites under the owning test phase:

• Linter.Repository / Linter.SourceCode
• Build.Module / Build.Docs / Build.Site
• Test.SourceCode.Suites, Test.PSModule.Suites, Test.Module.Suites
• Test.Module.BeforeAllEnabled, Test.Module.MainEnabled, Test.Module.AfterAllEnabled
• Test.TestResults.Enabled, Test.CodeCoverage.Enabled
• Publish.Module.Enabled, Publish.Site.Enabled

Changed: Workflows now consume the new phase-owned schema

Reusable workflows and the root workflow were updated to reference phase-local state instead of Settings.Run.* and Settings.TestSuites.*.

Changed: Version resolution is scoped under publish phase

Plan.yml now stores resolved version metadata under:

• Settings.Publish.Module.Resolution.Version
• Settings.Publish.Module.Resolution.Prerelease
• Settings.Publish.Module.Resolution.FullVersion
• Settings.Publish.Module.Resolution.ReleaseType
• Settings.Publish.Module.Resolution.CreateRelease

Build-Module.yml and Test-ModuleLocal.yml were updated to read this new location.

Changed: Settings schema deprecates root Run contract

Settings.schema.json no longer defines root TestSuites and marks root Run as deprecated.

Technical Details

• Preserved existing behavior by deriving phase Enabled values from the same event/state logic previously used to build Run.*.
• Kept the input settings shape stable for repository owners; this refactor targets the internal enriched settings object passed between workflow jobs.

Related issues

• Opened directly from maintainer request (no linked issue).

v6.1.10

🩹 [Patch]: Action changes now trigger workflow validation and release checks (#401)

Workflow-only pull requests now behave correctly when the changed code lives in .github/actions, so action updates are validated and considered for release automation without manual workaround.

Changed: Workflow test pipelines now include action-code changes

The workflow test entry points now trigger on .github/actions/** changes in addition to workflow file changes, and action paths are treated as important artifacts in bump classification.

Changed: Release workflow now runs when action files change

The release workflow path filter now includes .github/actions/**, so action updates are not skipped by path-based gating.

Fixed: Repo-linter class-file exclusions are scoped to the processed repository

Super-linter exclusions are now expressed relative to the current repository working directory, which avoids path-handling issues in both default repository linting and test-repo linting scenarios.

Fixed: Root-module relative path rendering is path-API based

Root-module build comments now derive relative folder/file paths via System.IO.Path APIs instead of regex path replacement, which keeps region naming stable across path separators.

Technical Details

• Updated workflow path filters and important-file patterns in Workflow-Test-Default.yml, Workflow-Test-WithManifest.yml, and Release.yml.
• Added scoped FILTER_REGEX_EXCLUDE values in Linter.yml and Lint-Repository.yml.
• Reworked relative-path generation in Add-ContentFromItem.ps1 and Build-PSModuleRootModule.ps1 to use GetRelativePath, ChangeExtension, and separator-safe splitting.
• Added/updated class-fixture files under tests/srcTestRepo and tests/srcWithManifestTestRepo for loader/linter coverage.

Related issues

• PSModule/CurseForge#38
• PSModule/Template-PSModule#30
• PSModule/WoW#36

v6.1.9

Treat BeforeAll module-local setup failures as catastrophic (#399)

Summary

• treat BeforeAll-ModuleLocal failure as a hard failure root cause in test result aggregation
• run AfterAll-ModuleLocal cleanup whenever module-local setup ran, even if setup failed and tests were skipped
• pass BeforeAll-ModuleLocal job result into Get-TestResults and fail early with a clear root-cause message
• document the new BeforeAllModuleLocalResult input in Get-PesterTestResults

Links

• Closes #388

v6.1.8

🩹 [Patch]: Consolidate Install-PSModuleHelpers into Install-PSModule (#397)

The Install-PSModuleHelpers action step has been consolidated under the unified Install-PSModule name across all workflow files and composite actions. Obsolete test fixture files that are no longer needed by the test repositories have also been removed.

• Fixes #347

Changed: Install step unified under Install-PSModule

The internal step name Install-PSModuleHelpers is renamed to Install-PSModule in all reusable workflows and composite actions. This affects:

• .github/workflows/AfterAll-ModuleLocal.yml
• .github/workflows/BeforeAll-ModuleLocal.yml
• .github/workflows/Build-Site.yml
• .github/workflows/Test-ModuleLocal.yml
• .github/actions/Build-PSModule/action.yml
• .github/actions/Document-PSModule/action.yml

There is no change to the behavior or inputs/outputs of these workflows — this is a naming consolidation only.

Changed: Obsolete test fixtures removed

Unused source files, icons, assemblies, and configuration fixtures from the test repositories (srcTestRepo and srcWithManifestTestRepo) have been removed, reducing noise in the repo and simplifying the test structure.

Technical Details

• All step references uses: ./_wf/.github/actions/Install-PSModuleHelpers replaced with uses: ./_wf/.github/actions/Install-PSModule.
• Deleted: src/assemblies/LsonLib.dll, src/classes/, src/data/, src/finally.ps1, icon/, README.md, mkdocs.yml, and several other fixtures from srcTestRepo.
• No consumer-visible API or behavior changes.

v6.1.7

🪲 [Fix]: TestData keys reach setup and teardown phases (#394)

TestData values now reach every module-local phase through the same export path. Setup scripts, module tests, and teardown scripts can rely on identical environment variable names for caller-provided secrets and variables, with secret masking preserved.

• Fixes #386

Fixed: Setup and teardown scripts receive TestData keys

BeforeAll-ModuleLocal, Test-ModuleLocal, and AfterAll-ModuleLocal now all call the same local Expose-TestData action after installing the shared helper module. This keeps TestData parsing, validation, masking, and GITHUB_ENV export behavior identical before each phase runs.

Callers continue to use the existing TestData workflow secret; no interface change is required.

Changed: TestData phase parity is documented

The README now states that the same TestData keys are available in setup, test, and teardown phases, and includes troubleshooting guidance for callers that use secrets: inherit without explicitly creating a TestData JSON payload.

Technical Details

• Added .github/actions/Expose-TestData/action.yml as the single workflow step wrapper around Import-TestData.
• Updated BeforeAll-ModuleLocal.yml, Test-ModuleLocal.yml, and AfterAll-ModuleLocal.yml to use the shared action.
• Added fixture assertions to both workflow test repositories so PSMODULE_TEST_SINGLELINE_SECRET and PSMODULE_TEST_VARIABLE are checked in BeforeAll.ps1, Pester tests, and AfterAll.ps1.
• Implementation plan progress: core shared export path, parity validation, setup/teardown regression coverage, and README guidance are complete.
• Local validation: helper test scripts passed; setup/teardown fixture assertions passed for both test repositories; touched workflow files passed actionlint with the repository's known job.workflow_repository/job.workflow_sha context warnings ignored.

v6.1.6

Bump PSModule/Invoke-Pester from 4.2.6 to 5.1.0 in the github-actions group across 1 directory (#393)

Bumps the github-actions group with 1 update in the / directory: PSModule/Invoke-Pester.

Updates PSModule/Invoke-Pester from 4.2.6 to 5.1.0

Release notes

Sourced from PSModule/Invoke-Pester's releases.

v5.1.0

🚀 [Minor]: Add optional GUID identity pinning to Pester selection (#73)

Adds an optional Guid input so a workflow can pin Pester by module identity (GUID), validated at install time. Combined with a #Requires GUID pin in test files, identity is validated the whole way — on the developer's machine and in CI at discovery, and now also in CI at the action's install step (shifted left, one clear failure point).

• Fixes #68

Added: Guid input for module-identity pinning

The optional Guid input pins Pester by module identity. After resolving and installing the version, the action validates the loaded module's GUID and fails fast if it does not match — guarding against a different module named Pester on the runner's PSModulePath.

- uses: PSModule/Invoke-Pester@v5
  with:
    Version: '6.0.0'
    Guid: 'a699dea5-2c73-4616-a270-1f7abb777e71'

Validation now happens at every layer:

• Developer machine / CI at test discovery — via #Requires -Modules @{ ...; GUID = ... } in test files.
• CI at the action's init/install step — via the new Guid input (earliest single point of failure).

Technical Details

• action.yml: new optional Guid input, passed to both the init and exec phases via PSMODULE_INVOKE_PESTER_INPUT_Guid.
• Install-PSResourceWithRetry: new -Guid parameter; after import, it validates the loaded module's Guid and throws a clear error on mismatch. Install-PSResource cannot select by GUID (gallery identity is name + version), so identity is enforced at import.
• init.ps1 / exec.ps1: read the input and pass -Guid through.
• Tests:
  • PesterGuidPin pins via both the Guid input and #Requires (validating the whole way).
  • PesterGuidMatch pins via the Guid input only (version-only #Requires), asserting a matching GUID lets the run succeed.
  • PesterGuidMismatch passes a wrong Guid and asserts the action fails.
• Docs: README input table updated.
• Verified locally: a correct GUID imports; a wrong GUID throws Loaded 'Pester' does not match the required GUID ....

This closes the last remaining item on #68 — the version-selection core shipped in #71 (v5.0.0), and this adds the optional GUID identity pin.

v5.0.0

🌟 [Major]: Version and Prerelease inputs now control Pester (#71)

Invoke-Pester now treats Version and Prerelease as Pester controls. Workflows that previously used those inputs to choose the GitHub PowerShell module used by the init bootstrap step must rename them to GitHubVersion and GitHubPrerelease. Workflows that did not set Version or Prerelease keep installing the latest available Pester by default.

• Related to #68
• Aligns with PSModule/GitHub-Script#97 for NuGet version-range syntax

Breaking Changes

Version and Prerelease now apply to Pester, not the GitHub PowerShell module used internally during init.

Before this change, a workflow like this selected the GitHub module version:

... (truncated)

Commits

• 4ff3319 🚀 [Minor]: Add optional GUID identity pinning to Pester selection (#73)
• 8a4e652 🌟 [Major]: Version and Prerelease inputs now control Pester (#71)
• 0a4e7b3 Bump actions/checkout from 6.0.2 to 7.0.0 (#66)
• 3299427 Bump super-linter/super-linter from 8.6.0 to 8.7.0 (#67)
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore <dependency name> major version will close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)
• @dependabot ignore <dependency name> minor version will close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)
• @dependabot ignore <dependency name> will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)
• @dependabot unignore <dependency name> will remove all of the ignore conditions of the specified dependency
• @dependabot unignore <dependency name> <ignore condition> will remove the ignore condition of the specified dependency and ignore conditions

v6.1.5

🩹 [Patch]: Actions are internalized and automatically follow the workflow version (#385)

When you reference Process-PSModule at a release tag, run it from a branch during development, or test it from a fork, the actions it calls now automatically match that same version. There's no more keeping a workflow and its actions in sync by hand — pin the workflow, and the actions follow.

• Fixes #384

New: Actions automatically follow the workflow version in use

Every stage workflow now checks out its own source at the exact commit it is running from, then calls its actions from that local copy instead of a separately pinned action reference. In practice this means:

• Reference a release tag → you get that tag's actions.
• Run a development branch → the branch's actions run together with it, with no separate action release or pin update needed to test a change.
• Fork the repository → your fork's actions are used, not upstream's.

This is possible using job.workflow_repository and job.workflow_sha, a set of GitHub Actions context properties that let a reusable workflow discover its own source repository and commit. This capability did not exist before — it was introduced by GitHub in April 2026 (shipped in Actions Runner v2.334.0, see actions/runner#4335) and is documented in the job context reference. No official GitHub changelog announcement could be found for this change — the runner release and context documentation are the primary references.

GitHub-Script, Invoke-Pester, and Invoke-ScriptAnalyzer continue to be consumed from their own repositories at pinned commits, as before.

No changes are required to consumer workflows. Inputs, outputs, and secrets are unchanged.

Changed: Internalized actions have moved out of their standalone repositories

Build-PSModule, Document-PSModule, Get-PSModuleSettings, Get-PesterCodeCoverage, Get-PesterTestResults, Initialize-PSModule, Install-PSModuleHelpers, Publish-PSModule, Resolve-PSModuleVersion, and Test-PSModule now ship directly inside Process-PSModule instead of living in their own PSModule repositories.

Those standalone repositories are now archived and will be deleted soon. If you reference any of them directly, switch to Process-PSModule instead. The old actions will also be the ones older versions of Process-PSModule will use, so be sure to update to be able to use the framework.

Technical Details

• Ten composite actions are now bundled under .github/actions/: Build-PSModule, Document-PSModule, Get-PSModuleSettings, Get-PesterCodeCoverage, Get-PesterTestResults, Initialize-PSModule, Install-PSModuleHelpers, Publish-PSModule, Resolve-PSModuleVersion, Test-PSModule.
• All stage workflows add a self-checkout step before any action call: repository: ${{ job.workflow_repository }}, ref: ${{ job.workflow_sha }}, path: _wf.
• Action call sites change from PSModule/<Name>@<sha> to ./_wf/.github/actions/<Name>.
• Nested dependencies on Install-PSModuleHelpers resolve from the same bundled revision.
• .github/actionlint.yaml is updated to recognize the self-checkout pattern and the job.workflow_* properties.
• Action READMEs and test-suite consolidation are out of scope for this change.

Validation

• MariusTestModule SHA-pinned consumer run passed.
• MariusTestModule ref-based consumer run passed and resolved feat/internalize-process-actions to the invoked workflow commit.

v6.1.4

🪲 [Fix]: Resolve the current version on non-PR runs (bump Resolve-PSModuleVersion to v1.1.5) (#375)

The Plan job no longer fails on schedule and workflow_dispatch events. Resolve-PSModuleVersion is bumped to v1.1.5, which resolves the current published version on non–pull-request events instead of throwing.

• Fixes #373

Fixed: non–pull-request runs (schedule / workflow_dispatch)

Since v6.1.0 the Plan job runs Resolve-Version on every event, and the action threw "...must be run from a pull_request event" on non-PR events — failing the whole run (every job needs: Plan). Resolve-PSModuleVersion v1.1.5 (PSModule/Resolve-PSModuleVersion#10) fixes this at the source: on a non-PR event it returns the current published version — no bump, no prerelease, nothing published — floored at 0.0.0 for a module that has never been released. Pull-request and merge-to-default-branch behavior is unchanged: labels drive the bump (patch default), and the version preview on regular PRs is retained.

Technical Details

• .github/workflows/Plan.yml: bump the Resolve-Version pin 8d1dac7 (v1.1.4) → 6a59a88 (v1.1.5). One-line change — no Plan gate or Test-ModuleLocal fallback is needed, because v1.1.5 always populates Settings.Module.Version on non-PR events.
• This supersedes this PR's earlier Plan.yml gate + 999.0.0 fallback approach, replaced by the root-cause fix in the shared action.
• Validated: a workflow_dispatch self-test run on this branch completes (previously failed at Plan); the PR self-test resolves a version as before.

v6.1.3

🩹 [Patch]: Bump Invoke-ScriptAnalyzer to v5.0.0 and Test-PSModule to v3.0.14 (#380)

Brings Process-PSModule's lint/test action dependencies to their latest releases: PSModule/Invoke-ScriptAnalyzer v4.1.3 → v5.0.0 and PSModule/Test-PSModule v3.0.13 → v3.0.14. Both preserve the reusable workflow's Settings.Version/Settings.Prerelease contract for consumers.

Changed: Invoke-ScriptAnalyzer upgraded to v5.0.0

Invoke-ScriptAnalyzer v5.0.0 is a major release that repurposed its Version/Prerelease inputs to select the PSScriptAnalyzer module version and moved the GitHub bootstrap-module controls to GitHubVersion/GitHubPrerelease.

The Lint-SourceCode and Lint-Module steps pass Settings.Version/Settings.Prerelease, which in this ecosystem select the GitHub module (the same values feed the Invoke-Pester and GitHub-Script steps). They are now wired to Invoke-ScriptAnalyzer's GitHubVersion/GitHubPrerelease, so those settings keep controlling the GitHub module exactly as before. No change to the Settings contract.

With v5, the action also installs PSScriptAnalyzer itself (latest, since its Version is left unset) instead of relying on the runner's preinstalled copy — so consumer linting now runs against the latest PSScriptAnalyzer.

Changed: Test-PSModule upgraded to v3.0.14

Patch release; Test-PSModule v3.0.14 (which internally bumped Invoke-Pester to v5.1.0) preserves its own Version/Prerelease (GitHub module) contract, so the Test-SourceCode and Test-Module steps need only a SHA update — no input remap.

Technical Details

• Lint-SourceCode.yml, Test-Module.yml: Invoke-ScriptAnalyzer 6aeb1bc (v4.1.3) → 4d633e4 (v5.0.0); remapped Version → GitHubVersion, Prerelease → GitHubPrerelease.
• Test-Module.yml, Test-SourceCode.yml: Test-PSModule 25c9cd8 (v3.0.13) → 902c5e5 (v3.0.14).
• Pester and PSScriptAnalyzer versions left at the v5 defaults (latest); not wired to any Settings key.
• Scope: the Invoke-Pester step (Test-ModuleLocal.yml, still v4.2.6) is intentionally untouched.
• Label note: the Settings contract is preserved (hence Patch), but consumer linting now runs against the latest PSScriptAnalyzer — bump to Minor if you'd rather signal that behavior change.

Release notes: Invoke-ScriptAnalyzer v5.0.0