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: Step conditions and result handling are explicit so each operation reports its own status regardless of another operation failing.

Release implementation: The release concern is delegated to a dedicated release action path aligned with repository conventions, with release-specific configuration passed only to that step.

Cleanup ownership: Prerelease cleanup remains a separate concern and is executed with explicit exclusion of the version or tag produced by the current run.

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

• 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