v1.5.0

🚀 [Feature]: Release-triggering file patterns now configurable (#19)

Repositories can now configure which file changes trigger build, test, and publish stages. Previously, only changes to src/ and README.md were recognized as significant — this was hardcoded and could not be overridden. Repositories that ship additional important files (e.g., examples/, custom config) can now declare their own patterns through the settings file or the action input.

• Fixes PSModule/Process-PSModule#278

New: Configurable important file patterns

The ImportantFilePatterns setting accepts an array of regex patterns. When a PR changes only files that don't match any pattern, build/test/publish stages are skipped.

Via settings file (.github/PSModule.yml):

ImportantFilePatterns:
  - '^src/'
  - '^README\.md$'
  - '^examples/'

Via action input (newline-separated):

- uses: PSModule/Get-PSModuleSettings@v1
  with:
    ImportantFilePatterns: |
      ^src/
      ^README\.md$
      ^examples/

The setting fully replaces the defaults when configured. Include the default patterns in your list if you still want them.

Resolution order: settings file → action input → hardcoded fallback (^src/, ^README\.md$).

Changed: PR skip comment now reflects configured patterns

The PR comment posted when no important files changed now dynamically lists the actual patterns in effect, rather than a hardcoded table.

Technical Details

• action.yml: Added ImportantFilePatterns input with newline-separated default and corresponding PSMODULE_GET_SETTINGS_INPUT_ImportantFilePatterns env var.
• Settings.schema.json: Added top-level ImportantFilePatterns property as array of strings.
• main.ps1: Added resolution logic (settings file → parsed input → hardcoded default). Replaced hardcoded $importantPatterns array with $settings.ImportantFilePatterns. Refactored PR comment to generate the pattern table dynamically.
• README.md: Documented the new input and settings file property with examples.

v1.4.4

🩹 [Patch]: BeforeAll/AfterAll-ModuleLocal jobs skipped when setup/teardown scripts do not exist (#18)

The BeforeAll-ModuleLocal and AfterAll-ModuleLocal workflow jobs no longer allocate runners when the corresponding tests/BeforeAll.ps1 or tests/AfterAll.ps1 scripts do not exist in the repository. Repositories without setup/teardown scripts now skip these jobs entirely, saving runner time on every workflow run.

• Fixes PSModule/Process-PSModule#288

Changed: Runner allocation for setup/teardown jobs

Previously, BeforeAll-ModuleLocal and AfterAll-ModuleLocal jobs always spun up a runner — even when the repository had no tests/BeforeAll.ps1 or tests/AfterAll.ps1 script. The runner would check out the repo, invoke the GitHub-Script action, find no script, and exit gracefully. This wasted runner time on every workflow run for the majority of repositories that have no setup/teardown requirements.

Now, the Get-PSModuleSettings action detects whether these scripts exist before setting the run flags. If a script is missing, the corresponding job flag is set to false and the workflow job is skipped before a runner is allocated.

Additionally, AfterAllModuleLocal was previously set to $true unconditionally, relying solely on the workflow-level if: condition to gate it. It now uses the same base conditions as BeforeAllModuleLocal ($shouldRunBuildTest -and ($null -ne $settings.TestSuites.Module)) combined with the script existence check. The workflow-level always() condition remains as an additional safeguard for cleanup-after-failure scenarios.

Repositories that include these scripts are unaffected — both jobs continue to run as before.

Technical Details

• In src/main.ps1, added Test-Path checks for tests/BeforeAll.ps1 and tests/AfterAll.ps1 in the 'Calculate Job Run Conditions' LogGroup block, before the $run object construction.
• BeforeAllModuleLocal flag updated from $shouldRunBuildTest -and ($null -ne $settings.TestSuites.Module) to $shouldRunBuildTest -and ($null -ne $settings.TestSuites.Module) -and $hasBeforeAllScript.
• AfterAllModuleLocal flag updated from $true to $shouldRunBuildTest -and ($null -ne $settings.TestSuites.Module) -and $hasAfterAllScript.
• Added log output for script existence detection, consistent with how other conditions are logged.
• No workflow YAML changes needed — the existing if: conditions in workflow.yml, BeforeAll-ModuleLocal.yml, and AfterAll-ModuleLocal.yml already respect these flags, and the in-workflow Test-Path guards remain as a safety net.

v1.4.3

🩹 [Patch]: Remove unimportant files from the importantFiles pattern list (#14)

Summary

Remove the Process-PSModule.yml workflow file pattern and examples/ directory from the important files list that determines whether a PR should trigger a release.

Changes

Modified

• src/main.ps1:
  • Removed .github/workflows/Process-PSModule.yml from the $importantPatterns array
  • Removed examples/ from the $importantPatterns array
  • Updated the documentation table in PR comments accordingly

Reason for Change

• Workflow file: Changes to the workflow file are maintenance/infrastructure changes, not functional changes to the module itself
• Examples: Examples are not currently included in documentation generation, so changes to them should not trigger releases

Impact

PRs that only modify the workflow file or example scripts will no longer trigger build, test, and publish stages unless other important files (src/ or README.md) are also modified.

Release Note

• Workflow file and example script changes no longer trigger module releases

v1.4.2

🩹 [Patch] Workflow improvements (#12)

This release introduces several improvements to the GitHub Actions workflows and the main PowerShell script for the repository. The main focus is to optimize CI/CD runs by detecting whether a pull request includes changes to important files (such as source code, examples, documentation, or workflow configurations). Build, test, and publish stages are now conditionally executed based on this detection, which helps save CI resources and provides clear feedback to contributors. Additionally, the workflows and dependencies have been updated and refactored for clarity and maintainability.

Workflow optimization and conditional execution:

• Added logic in src/main.ps1 to detect if a PR changes important files (src/**, examples/**, README.md, .github/workflows/Process-PSModule.yml). If not, build/test stages are skipped, and a comment is added to the PR explaining why. This is also reflected in the new HasImportantChanges property in both the script and Settings.schema.json.
• Updated the calculation of release and prerelease conditions to require important file changes for these actions, preventing unnecessary releases for trivial PRs.
• Refined job run conditions throughout the workflow to only run build, test, and publish steps if important files have changed, further optimizing CI usage.

Workflow and dependency updates:

• Updated actions/checkout and PSModule/GitHub-Script actions to their latest versions in all workflow files and action.yml for improved security and features.
• Changed the script path in action.yml to use src/main.ps1 instead of the old scripts/main.ps1 location.
• Renamed and refactored the release workflow from Auto-Release to Release, updated its triggering conditions, and switched to the new PSModule/Release-GHRepository action for releases.

Cleanup and configuration changes:

• Removed the .github/linters/.jscpd.json configuration file, possibly as part of linter or duplication check cleanup.
• Renamed and relocated schema and script files for clarity and better organization (e.g., scripts/Settings.schema.json to src/Settings.schema.json).

These changes collectively make the CI/CD workflows more efficient, transparent, and easier to maintain.

v1.4.1

🩹 [Patch]: Pin GitHub-Script action to specific version (#9)

The GitHub-Script action dependency is now pinned to a specific commit SHA (v1.7.8) for improved security and reproducibility. This ensures consistent builds and protects against potential supply chain attacks where action tags could be moved to point to malicious code.

Pin GitHub-Script action to specific SHA

Updated the action reference in action.yml from the previous SHA to the latest version:

Before	After
PSModule/GitHub-Script@8b9d2739d6896975c0e5448d2021ae2b94b6766a (v1.7.6)	PSModule/GitHub-Script@2010983167dc7a41bcd84cb88e698ec18eccb7ca (v1.7.8)

Why pin to SHA?

Pinning actions to specific commit SHAs is a security best practice that:

• Prevents tag mutation attacks - Tags can be moved, but SHAs are immutable
• Ensures reproducible builds - The exact same code runs every time
• Provides audit trail - Changes to dependencies are explicit and reviewable

v1.4.0

🚀 [Feature]: Separate cleanup from release type and move ReleaseType to Publish.Module (#8)

The release type calculation is now separated from cleanup logic, providing clearer control over when prereleases are cleaned up. The ReleaseType now only has three values (Release, Prerelease, or None), and cleanup is computed independently based on the AutoCleanup setting.

• Part of PSModule/Process-PSModule#73
• Part of PSModule/Process-PSModule#265

ReleaseType simplified to three values

Previously, ReleaseType could be set to Cleanup to trigger prerelease cleanup. Now, ReleaseType only has three values: Release, Prerelease, or None. The cleanup decision is computed separately based on:

1. Whether you're in a cleanup scenario (merging to main or abandoning a PR)
2. Whether AutoCleanup is enabled in your settings (defaults to true)

This separation enables the abandoned PR cleanup scenario where a PR is closed without merging—the workflow can now trigger cleanup independently of whether a release is being created.

ReleaseType moved to Publish.Module output

The computed ReleaseType value is now stored in Publish.Module.ReleaseType rather than in the Run object. This organizes release-related computed values alongside other publish settings.

Workflows should now reference:

• fromJson(inputs.Settings).Publish.Module.ReleaseType for the release type
• fromJson(inputs.Settings).Publish.Module.AutoCleanup for the cleanup decision (computed boolean)

AutoCleanup behavior

The AutoCleanup setting continues to work as before, but the output value is now a computed boolean that indicates whether cleanup should actually occur (based on both the setting and the current context like merged PR or abandoned PR).

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).