Decouple PowerShell Gallery publish from GitHub Release creation

[MariusStorhaug]

The publish workflow serves maintainers who need reliable module delivery and release communication on every qualifying pull request.

Request

Current experience

The current publish path combines PowerShell Gallery publishing and GitHub Release creation in the same action execution flow. These operations have different failure modes, so a failure in one path can obscure the result of the other and make retries and incident handling harder to reason about.

Desired experience

PowerShell Gallery publishing and GitHub Release creation are orchestrated as separate responsibilities with independent execution and reporting. Each operation can succeed or fail on its own, and the workflow communicates each result without ambiguity.

Acceptance criteria

• Publish-PSModule publishes to PowerShell Gallery only
• GitHub Release creation is executed in a separate workflow step or action using Release-GHRepository or an equivalent dedicated release path
• Failure in Gallery publishing does not suppress release-step execution logic, and failure in release creation does not rewrite the Gallery result
• PR feedback is operation-scoped for publish, release, and cleanup
• Existing release and prerelease behavior remains supported for the repository workflows

---

Technical decisions

Responsibility boundary: Publish-PSModule is treated as a Gallery-only action. Release creation logic and release-note inputs are removed from this action interface.

Workflow orchestration: .github/workflows/Publish-Module.yml owns cross-step sequencing and conditions. Publish, release, and cleanup are modeled as separate steps with explicit conditions.

Failure isolation: The release step runs after a Gallery failure unless the job is cancelled. Prerelease cleanup runs after a successful stable release or an abandoned PR, but never after a failed release attempt.

Version authority: Resolve-PSModuleVersion remains the single source of the GitHub release tag. The workflow passes Publish.Module.Resolution.FullVersion to the release action; the Gallery action derives only the package version from the built manifest.

Cleanup ownership: Prerelease cleanup remains a separate concern. Release-PSModule owns the release-tag context used to exclude the current tag from cleanup.

Compatibility stance: This is a workflow/action interface refactor with contained repository blast radius. Behavior remains functionally equivalent for supported publish and release flows.

---

Implementation plan

Publish action refactor

• Remove GitHub Release creation logic from .github/actions/Publish-PSModule/src/publish.ps1
• Remove release-specific inputs from .github/actions/Publish-PSModule/action.yml
• Keep manifest validation, dependency resolution, Gallery publish, and Gallery-scoped PR feedback in Publish-PSModule

Workflow orchestration changes

• Add a dedicated release step in .github/workflows/Publish-Module.yml
• Map release-specific settings only to the release step
• Keep publish, release, and cleanup conditions explicit and independently understandable

Cleanup and context wiring

• Preserve cleanup as a separate step and keep exclusion of the currently produced release tag or version
• Ensure cleanup messaging remains scoped to cleanup outcomes

Validation coverage

• Add a no-side-effect WhatIf test for prefixed prerelease release creation
• Validate prerelease flow behavior across publish, release, and cleanup
• Validate merged-release flow behavior across publish, release, and cleanup
• Validate failure-isolation behavior where publish and release fail independently

[MariusStorhaug]

Updated the issue description to align with the MSX Issue Format standard.

• Reframed Section 1 as user-facing context and request (current vs desired experience plus acceptance criteria)
• Rewrote Section 2 as explicit technical decisions with rationale for boundaries and orchestration
• Rebuilt Section 3 as a concrete checkbox implementation plan grouped by action, workflow, cleanup, and validation
• Tightened title to imperative form for clearer scope

[MariusStorhaug]

Updated the implementation plan after rebasing the split work onto current main.

• Marked the Gallery-only action, release-step orchestration, and cleanup-context tasks complete
• Recorded Resolve-PSModuleVersion as the single release-tag authority
• Added the completed no-side-effect WhatIf validation task
• Left full prerelease, merged-release, and failure-isolation workflow validation open because CI still skips publish jobs for ordinary PR events