🚀 [Feature]: Add PR Title and Description as Configurable Release Notes

[MariusStorhaug]

Your pull request title and description can now be used as release notes when publishing modules, giving you direct control over how your releases appear to users. Additionally, this PR updates the workflow to pass the computed ReleaseType from Get-PSModuleSettings to Publish-PSModule.

• Fixes 🩹 [Patch]: When a PR is closed, but not merged, fast forward to cleanup of prereleases. #73
• Fixes 🚀 [Feature]: Add PR Title and Description as Configurable Release Notes #263

New configuration settings

Three new settings are available in your .github/PSModule.yml file under Publish.Module:

Setting	Default	Description
UsePRTitleAsReleaseName	false	Use the PR title as the GitHub release name instead of version string
UsePRBodyAsReleaseNotes	true	Use the PR description as the release notes content
UsePRTitleAsNotesHeading	true	Prepend PR title as H1 heading with PR number link in release notes

Default behavior

With the default settings, when you merge a PR, the GitHub release will automatically include:

• A heading with your PR title and a link to the PR (e.g., # Add retry logic (#123))
• Your PR description as the release notes body

No configuration changes are needed to benefit from this feature—just write meaningful PR descriptions.

Usage examples

To use all default settings (recommended):

# No configuration needed - defaults work out of the box

To also use the PR title as the release name:

Publish:
  Module:
    UsePRTitleAsReleaseName: true

To disable PR-based release notes entirely (use auto-generated notes):

Publish:
  Module:
    UsePRBodyAsReleaseNotes: false
    UsePRTitleAsNotesHeading: false

Updated workflow references

The workflow now passes ReleaseType from Get-PSModuleSettings to Publish-PSModule, enabling explicit control over the release type. The ReleaseType is computed in Get-PSModuleSettings and stored in Publish.Module.ReleaseType.

[Copilot]

Pull request overview

This PR adds three new configurable settings for release notes generation based on pull request metadata, aligning with the Auto-Release pattern. The changes enable users to customize whether the PR title is used as the release name, whether the PR body becomes the release notes content, and whether the PR title appears as a heading above the body.

Changes:

• Added three new boolean settings to the Publish.Module configuration section
• Updated the workflow to pass these settings to the Publish-PSModule action
• Documented the new settings in the README configuration table and defaults example

Reviewed changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.

File	Description
README.md	Adds documentation for three new Publish.Module settings (UsePRTitleAsReleaseName, UsePRBodyAsReleaseNotes, UsePRTitleAsNotesHeading) in both the configuration table and defaults YAML example
.github/workflows/Publish-Module.yml	Passes the three new settings from the configuration to the Publish-PSModule action

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.

[Copilot]

Pull request overview

Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated 4 comments.

[Copilot]

Pull request overview

Copilot reviewed 4 out of 4 changed files in this pull request and generated no new comments.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 4 comments.

[Copilot]

According to the Markdown style guidelines (CodingGuidelineID: 1000002), code fence blocks should always be followed by a blank line before continuing with regular text. Add a blank line after the closing code fence and before "#### Auto-generated notes".

[Copilot]

The PR description mentions that the workflow now uses Publish.Module.ReleaseType, and this setting is passed to the Publish-PSModule action on line 56. However, this setting is not documented in the configuration table (lines 366-409) or in the default configuration example. The ReleaseType setting should be added to the documentation to maintain completeness.

[Copilot]

The documentation table uses regular hyphens in the parameter names which can cause line breaks within the parameter names. According to the Markdown style guidelines (CodingGuidelineID: 1000002), these should use non-breaking hyphens. Replace regular hyphens with non-breaking hyphens for UsePRTitleAsReleaseName, UsePRBodyAsReleaseNotes, and UsePRTitleAsNotesHeading.

[Copilot]

According to the Markdown style guidelines (CodingGuidelineID: 1000002), code fence blocks should always be followed by a blank line before continuing with regular text. Add a blank line after the closing code fence and before "This produces release notes like:".

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 3 comments.

[Copilot]

The workflow is referencing a feature branch instead of a stable release tag. Using branch references (like @feature/releasetype-input) in production workflows creates instability as the branch content can change unexpectedly. Consider using a specific commit SHA or version tag once the feature is merged and released.

Suggested change

	uses: PSModule/Publish-PSModule@feature/releasetype-input
	uses: PSModule/Publish-PSModule@v1

[Copilot]

The workflow is referencing a cleanup branch instead of a stable release tag. Using branch references (like @cleanup) in production workflows creates instability as the branch content can change unexpectedly. Consider using a specific commit SHA or version tag once the feature is merged and released.

Suggested change

	uses: PSModule/Get-PSModuleSettings@cleanup
	uses: PSModule/Get-PSModuleSettings@v1

[Copilot]

The new Publish.Module.ReleaseType setting is being passed to the Publish-PSModule action but is not documented in the configuration settings table or in the default settings example. According to the PR description, this setting moved from Run.ReleaseType to Publish.Module.ReleaseType, but users need to know what values this setting accepts and what its purpose is.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

[Copilot]

The removal of the "Download module artifact" and "Update Microsoft.PowerShell.PSResourceGet" steps suggests these are now handled internally by the new action version. However, this creates a dependency on the feature branch implementation. If the action doesn't handle artifact download internally, the publish step will fail. Consider verifying that the referenced action version (feature/releasetype-input) properly handles module artifact retrieval, or document this dependency change in the PR description.

Suggested change

	uses: PSModule/Publish-PSModule@feature/releasetype-input
	uses: PSModule/Publish-PSModule@v1

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

.github/workflows/Publish-Module.yml:38

• The artifact download and PSResourceGet update steps have been removed, but the workflow still references ModulePath: outputs/module on line 38. Without downloading the module artifact first, the outputs/module directory will not exist, causing the publish step to fail. These removed steps appear necessary for the workflow to function correctly.

      - name: Publish module
        uses: PSModule/Publish-PSModule@feature/releasetype-input
        env:
          GH_TOKEN: ${{ github.token }}
        with:
          Name: ${{ fromJson(inputs.Settings).Name }}
          ModulePath: outputs/module