Restore CI by updating the pinned Process-PSModule workflow reference

[MariusStorhaug]

The Process-PSModule workflow fails on every run, including scheduled runs against main, before any job does useful work. Every downstream job — build, lint, test, code coverage, publish — is skipped, so the repository currently has no working CI and no signal on any pull request.

Request

Current experience

Get-Settings fails after about two seconds with:

##[error]Unable to resolve action psmodule/get-psmodulesettings, repository not found

PSModule/get-PSModuleSettings no longer exists. It is referenced from inside PSModule/Process-PSModule, which .github/workflows/Process-PSModule.yml pins to 205d193f34cbbaf9992955c21d842bcf98a1859f (v5.4.6). The current release of Process-PSModule is v8.0.0.

The last four scheduled Process-PSModule runs on main all ended in failure for this reason, and pull requests inherit it — #37 shows the same failure with a documentation-only diff.

Desired experience

Process-PSModule resolves every action it references, and the jobs it gates actually run, so a pull request gets a real verdict rather than a resolution error.

Acceptance criteria

• Get-Settings completes rather than failing to resolve an action.
• The build, lint, and test jobs execute instead of being skipped.
• A scheduled run on main reports a status that reflects the repository's actual state.
• The workflow reference stays pinned to an immutable SHA with the version recorded in a trailing comment, as it is today.

Out of scope

• Any change to module source, documentation, or tests. This is a pipeline fix.
• Adopting new Process-PSModule capabilities beyond what is needed to make the pipeline resolve and run.

---

Technical decisions

The fix is a version bump, not a workaround. The missing action is referenced from within the reusable workflow, so it cannot be corrected from this repository except by moving to a Process-PSModule version that no longer references it. Pinning to a newer SHA is the whole change.

Crossing v6, v7, and v8 needs its release notes read first. Three major versions have shipped since v5.4.6, so the bump may require configuration changes in .github/PSModule.yml or elsewhere. The upgrade notes decide whether the bump is one line or several.

Verify on a pull request before merging. The failure is only visible from a run, so the branch carrying the bump has to show Get-Settings passing and the downstream jobs executing.

---

Implementation plan

• Read the Process-PSModule release notes for v6, v7, and v8 and note any required configuration changes
• Update the pinned reference in .github/workflows/Process-PSModule.yml to the current release SHA, keeping the version comment accurate
• Apply any configuration changes the upgrade requires
• Confirm on the pull request that Get-Settings passes and the build, lint, and test jobs run

[MariusStorhaug]

Widened this beyond the repository. Swept the organization on 2026-08-15: 43 repositories are pinned to Process-PSModule v5 and 17 are on v6 or later, so this is not a Markdown problem. Verified directly rather than inferred from the pin — Base64, Context, Utilities, Uri, and Guid all show failing runs on main.

Raised as PSModule/Process-PSModule#516, since the fix belongs where the breaking change happened rather than in 43 separate repositories.

The fix for this repository is already open and green. #29 moves the workflow to v6.1.4, is not a draft, and its checks pass — Plan and Lint-Repository both succeed, which is exactly what fails on main today. #35 bumps further to v6.1.16. So CI here is red while a reviewed-and-passing fix sits waiting.

That is worth stating plainly, because it is the second time on this work that an unreviewed pull request has caused a downstream problem: MSXOrg/docs#144 drifted into a merge conflict after a week, and a stood-down session opened a duplicate of it.

Keeping this issue open is still right \u2014 it records the repository-level symptom and the diagnosis. But it is resolved by merging #29, not by separate work here.