🚀 [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`):

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

**Via action input** (newline-separated):

```yaml
- 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.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

🚀 [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`):

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

**Via action input** (newline-separated):

```yaml
- 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.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

🚀 [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`):

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

**Via action input** (newline-separated):

```yaml
- 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.

---------

Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com>

🩹 [Patch]: BeforeAll/AfterAll-ModuleLocal jobs skipped when setup/tea…

…rdown 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.

🩹 [Patch]: BeforeAll/AfterAll-ModuleLocal jobs skipped when setup/tea…

…rdown 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.

🩹 [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

🩹 [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.

🩹 [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

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

🚀 [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
```