🩹 [Patch]: Add path filter to Auto-Release workflow

[Copilot]

Auto-Release currently triggers on every PR merge to main, creating releases for documentation, test data, and metadata changes. This inflates version numbers without delivering value to consumers.

Changes

Added paths filter to .github/workflows/Auto-Release.yml:

on:
  pull_request:
    branches:
      - main
    types:
      - closed
      - opened
      - reopened
      - synchronize
      - labeled
    paths:
      - '.github/workflows/**'
      - '.github/linters/**'

Behavior

Triggers release:

• Changes to .github/workflows/** (reusable workflows)
• Changes to .github/linters/** (workflow-consumed configs)

Skips release:

• Documentation (README.md, *.md)
• Test data (tests/**)
• Media, editor config, git config
• Repo metadata (.github/CODEOWNERS, .github/dependabot.yml, .github/instructions/**)

Aligns with the pattern used in action repositories (action.yml, src/**), adapted for a reusable workflow repository where workflows and linter configs are the product.

Original prompt

---

This section details on the original issue you should resolve

<issue_title>Add path filter to Auto-Release workflow to only trigger on significant file changes</issue_title>
<issue_description>### Describe the change

The Auto-Release.yml workflow currently has no paths filter, meaning every PR merged to main triggers a release — even for changes to documentation, tests, media, or editor configuration. This creates unnecessary releases that provide no value to consumers of the reusable workflows.

All action repos (e.g., Build-PSModule, GitHub-Script, Publish-PSModule) already use a paths filter on their Release workflow:

paths:
  - 'action.yml'
  - 'src/**'

The Process-PSModule repo should follow the same pattern, but with paths appropriate for a reusable workflow repository rather than an action repository.

Problem Statement

Currently, every merged PR triggers a release, even when:

• Only CI/CD configuration files are changed (e.g., internal workflow files)
• Only repository metadata files are changed (e.g., README badges, CODEOWNERS)
• Changes are made to unrelated parts of the repository (tests, media, editor config)
• Whitespace-only or formatting-only changes occur in non-source files

This results in:

• Version number inflation without meaningful changes for consumers
• Unnecessary churn for users pinning to release tags
• Confusion for users tracking workflow updates
• Increased noise in release notifications

Analysis of the repository

The repo has the following structure:

Process-PSModule/
├── .github/
│   ├── workflows/          # 20 reusable workflow files (the product)
│   │   ├── workflow.yml    # Main entry point
│   │   ├── Build-Module.yml
│   │   ├── Get-Settings.yml
│   │   ├── Lint-Repository.yml
│   │   ├── Test-Module.yml
│   │   ├── Publish-Module.yml
│   │   ├── ... (15 more reusable workflows)
│   │   ├── Auto-Release.yml            # Internal: release workflow
│   │   ├── Workflow-Test-Default.yml   # Internal: test workflow
│   │   └── Workflow-Test-WithManifest.yml  # Internal: test workflow
│   ├── linters/            # Linter configs used by workflows
│   │   ├── .markdown-lint.yml
│   │   ├── .powershell-psscriptanalyzer.psd1
│   │   └── .textlintrc
│   ├── instructions/       # Copilot instructions (not consumed by users)
│   ├── CODEOWNERS
│   └── dependabot.yml
├── tests/                  # Test data repos
├── media/                  # Media assets
├── README.md
├── LICENSE
├── .gitignore
├── .gitattributes
└── .vscode/

Proposed path filter

Files that SHOULD trigger releases (consumed by workflow callers):

• .github/workflows/** — All reusable workflow definitions
• .github/linters/** — Linter configurations used by the workflows

Files that SHOULD NOT trigger releases:

• tests/** — Test data/repos
• README.md — Documentation
• LICENSE — License
• media/** — Media assets
• .gitignore / .gitattributes — Git configuration
• .vscode/** — Editor settings
• .github/instructions/** — Copilot instructions
• .github/CODEOWNERS — GitHub ownership config
• .github/dependabot.yml — Dependabot config

Version bump behavior

When a release IS triggered, the existing version bump behavior should remain as-is:

• Patch label or default → Patch version bump
• Minor label → Minor version bump
• Major label → Major version bump

Edge cases

• First release: If no previous release exists, any change should trigger a release
• Force release: Consider supporting a mechanism to force a release via PR label (e.g., force-release) even when no significant files changed — useful for cases where a rebuild with identical workflow content is needed

Implementation

Update .github/workflows/Auto-Release.yml to add a paths filter:

on:
  pull_request:
    branches:
      - main
    types:
      - closed
      - opened
      - reopened
      - synchronize
      - labeled
    paths:
      - '.github/workflows/**'
      - '.github/linters/**'

This aligns with the pattern used across all action repos, adapted for a reusable workflow repository where .github/workflows/** and .github/linters/** are the product instead of action.yml and src/**.

User scenarios

1. Workflow file change — A PR modifies .github/workflows/Build-Module.yml → Release SHOULD be created
2. Linter config change — A PR modifies .github/linters/.textlintrc → Release SHOULD be created
3. README-only change — A PR only updates README.md → NO release should be created
4. Test data change — A PR only modifies files in tests/ → NO release should be created
5. Mixed change — A PR modifies both README.md and .github/workflows/workflow.yml → Release SHOULD be created (path filter matches at least one file)

Supersedes

• 🩹 [Patch]: Only create releases when significant changes are detected (module and documentation) #184 — Original issue covering change detection for releases. That issue also discussed consu...

Custom agent used: PR Manager
Create a pull request with a release note style description, appropriate title, and labels based on the change type.

• Fixes Add path filter to Auto-Release workflow to only trigger on significant file changes #282

---

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

[Copilot]

Pull request overview

This PR adds path filtering to the Auto-Release workflow to prevent unnecessary releases when only documentation, test data, or metadata files are changed. The workflow will now only trigger when changes affect .github/workflows/** or .github/linters/**, which are the consumable products of this reusable workflow repository.

Changes:

• Added paths filter to Auto-Release workflow limiting triggers to workflow and linter configuration files

[Copilot]

The paths filter does not apply to the labeled event type in GitHub Actions. When a label is added to a PR (e.g., Major, Minor, Patch), the workflow will trigger regardless of which files were changed, because label events don't have associated file changes to filter against.

This means a PR that only changes README.md or test files will still trigger the Auto-Release workflow when labeled, potentially creating an unwanted release.

Consider one of these solutions:

1. Remove labeled from the event types if label changes alone should not trigger releases
2. Add a conditional check in the job using if: to verify that the PR contains changes to the filtered paths before proceeding with the release
3. Accept this behavior if the intent is to allow manual release triggers via labels even when only documentation changes

Suggested change

- labeled