Bump PSModule/Process-PSModule/.github/workflows/workflow.yml from 6.1.4 to 6.1.16

[dependabot]

Bumps PSModule/Process-PSModule/.github/workflows/workflow.yml from 6.1.4 to 6.1.16.

Release notes

Sourced from PSModule/Process-PSModule/.github/workflows/workflow.yml's releases.

v6.1.16

🪲 [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:

	Value
GitHub release tag and title	v1.1.10
PowerShell Gallery version	1.1.10
Manifest ModuleVersion	1.1.10
Attached artifact	MyModule-1.1.10.zip

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.

---

What changed

• .github/actions/Publish-PSModule/src/Publish-PSModule.Helpers.psm1 — new action-scoped helper module with Get-ModuleVersionString, which composes the module's SemVer string, and Get-ReleaseTag, which prefixes it.
• .github/actions/Publish-PSModule/src/publish.ps1 — reads the new VersionPrefix input, derives both version strings from those helpers in one place, and reports both in the resolved-version summary and the closing log line.
• .github/actions/Publish-PSModule/action.yml — new optional VersionPrefix input, defaulting to ''.
• .github/workflows/Publish-Module.yml — passes Settings.Publish.Module.VersionPrefix into the action.
• .github/actions/Publish-PSModule/tests/Publish-PSModule.Helpers.Tests.ps1 — new Pester suite, picked up automatically by the existing Test-Actions discovery over .github/actions/*/tests.

Five files, all on the tag-derivation path. No test fixture or pipeline behaviour outside it changes.

Approach

The manifest stays the source of the numeric version. ModuleVersion is what was built, tested, and pushed to the Gallery, so the tag has to agree with it — the ^\d+\.\d+\.\d+$ guard and the 999.0.0 placeholder check are unchanged. Only the prefix, the one piece of the tag the manifest cannot carry, is taken from the settings the Plan job already resolves. Composing the two is equivalent to using Resolution.FullVersion in the normal case and stays anchored to the artifact if the two ever disagree.

Keeping the prefix off the module version. publish.ps1 previously built the Gallery version with its own copy of the prerelease composition, independent of the tag. Two independent implementations of the same string is how they drift, and drift in this direction means a prefixed version reaching Publish-PSResource. Both now come from Get-ModuleVersionString; Get-ReleaseTag is that string with the prefix in front, so the prefix is the only possible difference between them, by construction rather than by convention.

The prefix reaches: the release tag, the release title fallback, the gh release upload target, the release URL, the GitHub half of the pull request comment, and PSMODULE_PUBLISH_PSMODULE_CONTEXT_ReleaseTag for cleanup. It reaches nothing else. publish.ps1 never writes to the manifest — it is read-only on the artifact by design — and Build-PSModule stamps the manifest from Resolution.Version and Resolution.Prerelease, which are unprefixed. Resolution.FullVersion, the one prefix-bearing value in the Settings object, is consumed by no downstream job.

... (truncated)

Commits

• 1653be8 🪲 [Fix]: Release tags keep the configured version prefix (#440)
• 688896d 🪲 [Fix]: Version resolution no longer fails on repositories without releases ...
• b11b310 ⚙️ [Maintenance]: Public help links follow canonical documentation paths (#420)
• 9bca3f5 ⚙️ [Maintenance]: Module source tests align with latest PowerShell LTS (#419)
• fb1bdb8 ⚙️ [Maintenance]: Minor docs-site switch to Zensical (#403)
• 0307c0d 🩹 [Patch]: Prerelease cleanup no longer depends on module artifact (#400)
• 5998e39 ⚙️ [Maintenance]: Internalize runtime settings by phase (#402)
• 7ad7d26 🩹 [Patch]: Action changes now trigger workflow validation and release checks ...
• 317bcb1 Treat BeforeAll module-local setup failures as catastrophic (#399)
• 025d6a2 🩹 [Patch]: Consolidate Install-PSModuleHelpers into Install-PSModule (#397)
• Additional commits viewable 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 this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

[dependabot]

Labels

The following labels could not be found: github-actions. Please create it before Dependabot can add it to a pull request.

Please fix the above issues or remove invalid values from dependabot.yml.

[github-actions]

No Significant Changes Detected

This PR does not contain changes to files that would trigger a new release:

Pattern	Description
^src/	Matches files where path matches this pattern
^README\.md$	Matches files where path matches this pattern

Build, test, and publish stages will be skipped for this PR.

If you believe this is incorrect, please verify that your changes are in the correct locations.

[github-actions]

Super-linter summary

Language	Validation result
CHECKOV	Pass ✅
GITHUB_ACTIONS	Pass ✅
GITLEAKS	Pass ✅
GIT_MERGE_CONFLICT_MARKERS	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