v1.3.0

🚀 [Feature]: Add target branch detection to prevent releases from non-default branch merges (#7)

The action now detects whether a pull request targets the repository's default branch and uses this to determine the correct release type. Releases and site deployments are only triggered when PRs are merged into the default branch, preventing accidental releases from feature branch merges.

Target branch detection

Added detection logic to identify the PR's target branch and compare it against the repository's default branch:

• targetBranch - Extracted from the PR's base ref (pullRequest.Base.Ref)
• defaultBranch - Retrieved from repository info (eventData.Repository.default_branch)
• isTargetDefaultBranch - Boolean flag indicating whether the PR targets the default branch

ReleaseType logic update

The ReleaseType calculation now factors in the target branch:

Condition	ReleaseType
PR merged to default branch	Release
PR merged to non-default branch	None
PR closed without merge	Cleanup
Open PR with prerelease label	Prerelease
Everything else	None

This ensures that PRs merged into feature branches or other non-default branches do not trigger releases.

Site publishing update

The PublishSite condition now also requires the PR to be merged into the default branch ($isMergedPR -and $isTargetDefaultBranch), ensuring sites are only deployed when merging to the main branch.

Code simplification

Simplified the event data extraction by removing defensive null-checking in favor of relying on Get-GitHubEventData to provide valid data. The action now uses direct property access for cleaner, more readable code.

Logging improvements

The GitHub event inputs logging now includes branch information for debugging:

TargetBranch          : main
DefaultBranch         : main
IsTargetDefaultBranch : True

v1.2.0

🚀 [Feature]: Add PrereleaseLabels support and ReleaseType calculation (#6)

The workflow now supports configurable prerelease labels and introduces ReleaseType as a single source of truth for determining what action the publish workflow should take. Previously, the prerelease label check was hardcoded while all other labels were configurable, and adding a prerelease label to a PR did not trigger the publish workflow.

PrereleaseLabels Configuration

You can now customize which labels trigger a prerelease build via the PSModule.yml settings file:

Publish:
  Module:
    PrereleaseLabels: prerelease, beta, alpha

The default value is prerelease, maintaining backward compatibility.

ReleaseType - Single Source of Truth

A new ReleaseType property is now calculated and included in the Run object with these values:

Value	Trigger	Action
Release	PR merged to default branch	Create stable release
Prerelease	PR has prerelease label OR prerelease label just added	Create prerelease
Cleanup	PR closed without merge (abandoned)	Delete old prereleases
None	Any other scenario	Skip publishing

This simplifies the publish logic and makes debugging easier since ReleaseType is visible in the Get-Settings logs.

Changes

• Added PrereleaseLabels setting with default value prerelease
• Added detection for when a prerelease label is added via the labeled action
• Introduced ReleaseType calculation as the single source of truth
• Updated PublishModule condition to use $releaseType -ne 'None'
• Added ReleaseType to the Run object for downstream consumption
• Updated JSON schema with PrereleaseLabels and ReleaseType definitions

v1.1.0

🚀 [Feature]: Add PR-based release notes settings (#5)

The settings action now supports three new configuration options that control how GitHub release notes are generated from pull requests.

• Relates to PSModule/Process-PSModule#263

New settings schema

The following settings are now available in the Publish.Module section of your .github/PSModule.yml:

Setting	Type	Default	Description
UsePRTitleAsReleaseName	boolean	false	Use pull request title as the GitHub release name
UsePRBodyAsReleaseNotes	boolean	true	Use pull request body as the release notes content
UsePRTitleAsNotesHeading	boolean	true	Add pull request title as H1 heading in release notes

Schema changes

The JSON schema in scripts/Settings.schema.json has been updated to include the new properties with proper type definitions and descriptions.

Default values

The scripts/main.ps1 file now outputs these settings with sensible defaults:

• UsePRTitleAsReleaseName: false (release name uses version tag)
• UsePRBodyAsReleaseNotes: true (PR body becomes release notes)
• UsePRTitleAsNotesHeading: true (PR title appears as heading with PR link)

v1.0.3

Handle PascalCase PR event payload keys (#4)

• Handle Action/PullRequest casing in event payloads when determining PR action and merged status.

Fixes

• Fixes PSModule/Process-PSModule#260

Testing

• Not run (logic-only change).

v1.0.2

🩹 [Patch]: Correct how we get pull request info (#3)

This release updates the logic for processing GitHub event data in scripts/main.ps1, making the workflow more robust and accurate when handling pull request events. The main improvements focus on how event data is retrieved and how pull request states are determined.

Event Data Handling Improvements:

• Added logic to retrieve and parse GitHub event data more reliably, including a fallback to read and parse the event file if the primary method fails.
• Introduced a dedicated logging group to output the full event data for easier debugging.

Pull Request State Calculation Enhancements:

• Refactored how pull request action and merged status are determined, using parsed event data instead of relying solely on environment variables.
• Updated the conditions for identifying open/updated, abandoned, and merged pull requests to use the improved event data logic, ensuring more accurate state detection.

v1.0.1

🩹[Patch]: Fix repo linting on merge to main (#2)

This release updates the logic for determining pull request states in the scripts/main.ps1 script, making the conditions for open, updated, abandoned, and merged pull requests more precise and adding improved logging for GitHub event inputs.

• Fixes PSModule/Process-PSModule#256

Improvements to PR state detection:

• Refined the $isOpenOrUpdatedPR condition to trigger only for 'opened', 'reopened', or 'synchronize' actions, making it more accurate than the previous logic.
• Updated the $isMergedPR condition to require both the 'closed' action and that the PR is marked as merged, preventing false positives.

Logging enhancements:

• Added output of relevant GitHub event environment variables at the start of the job run conditions calculation for easier debugging and traceability.

v1.0.0

🌟[Major] Introducing Get-PSModuleSettings GitHub Action (#1)

This release introduces a new GitHub Action, Get-PSModuleSettings, which replaces the previous template action in PSModule/Process-PSModule. The action is designed to load and process PowerShell module workflow settings from configuration files, compute job run conditions, and output structured settings and test suite information for use in CI pipelines.

How It Works

The Get-PSModuleSettings action:

1. Loads settings from a specified configuration file (supporting JSON, YAML, or PSD1 formats)
2. Validates settings against a comprehensive JSON schema to ensure correctness
3. Applies defaults for any missing configuration values
4. Generates test suite matrices for multiple operating systems (Linux, macOS, Windows) based on test discovery
5. Computes job run conditions based on PR state (open, updated, merged, abandoned)
6. Outputs structured JSON containing all settings, test suites, and run conditions for downstream workflow steps

Configuration Format Support

The action supports three configuration formats:

• JSON - Standard JSON configuration files
• YAML/YML - Human-readable YAML format
• PSD1 - PowerShell Data File format (native PowerShell hashtables)

Test Suite Generation

The action automatically discovers and categorizes tests into three types:

• SourceCode tests - Static analysis and linting of source code
• PSModule tests - Tests for the built PowerShell module
• Module tests - Integration and functional tests with test matrices for each OS

Test discovery supports:

• *.Configuration.ps1 - Test configuration files
• *.Container.ps1 - Test container files
• *.Tests.ps1 - Standard Pester test files

Job Run Conditions

The action calculates intelligent run conditions for each workflow job based on:

• Pull request state (open, updated, merged, abandoned)
• Configuration skip flags
• Test suite availability
• Ensures abandoned PRs don't waste CI resources