Skip to content

Releases: PSModule/Process-PSModule

v5.3.0

11 Oct 22:07
c774534

Choose a tag to compare

🚀[Feature]: Use local PSScriptAnalyzer files (#228)

The workflow now uses Invoke-ScriptAnalyzer@v4, enabling automatic discovery of local PSScriptAnalyzer configuration files. This allows projects to maintain custom linting rules in their repository without requiring centralized settings management. The upgrade also streamlines workflow configuration by removing deprecated parameters and improving checkout efficiency.

Updated to PSScriptAnalyzer v4

Upgraded the PSModule/Invoke-ScriptAnalyzer action from v3 to v4 in linting workflows (Lint-SourceCode.yml and Test-Module.yml). This version automatically discovers and uses local .powershell-psscriptanalyzer.psd1 configuration files from the .github/linters/ directory, providing better support for repository-specific linting rules.

Removed Deprecated Settings Parameter

The Settings parameter has been removed from both Lint-SourceCode and Lint-Module workflow steps. PSScriptAnalyzer now automatically discovers local configuration files, eliminating the need to explicitly specify settings profiles.

Workflow Configuration Improvements

  • Added a Checkout repository step to the Lint-Module job to ensure the codebase (including local configuration files) is available before linting
  • Removed fetch-depth: 0 from checkout steps to use shallow clones, reducing workflow execution time
  • Removed unused Name parameter from test workflow

Custom Linting Configuration Support

Added a .powershell-psscriptanalyzer.psd1 configuration file in the test repository (tests/srcWithManifestTestRepo/.github/linters/) demonstrating how projects can define custom code style rules, including formatting preferences, line length limits, and rule exclusions.

v5.2.1

08 Oct 20:47
6090b7e

Choose a tag to compare

📖Docs: Update README.md with new use cases (#227)

Description

This pull request updates the workflow configuration in the README.md to enhance automation and permissions, and to use the latest workflow version. The most important changes are:

Workflow triggers and scheduling:

  • Added workflow_dispatch and a nightly scheduled run (cron: '0 0 * * *') to allow manual and automated executions of the workflow.

Permissions:

  • Expanded required permissions to include statuses, pages, and id-token in addition to contents and pull-requests.

Workflow version:

  • Updated the referenced workflow from version v2 to v5 for the Process-PSModule job.

v5.2.0

08 Oct 20:25
ea29e6b

Choose a tag to compare

🚀[Feature]: Linting and Documentation Improvements with Conditional Summary Option (#226)

This pull request introduces improvements to the linting workflows and documentation, adds new configuration options for linter summary reporting, and updates test scripts for better visibility. The main focus is on allowing users to optionally display the super-linter summary even when no issues are found, and on clarifying documentation and prompts related to repository operations.

Workflow and Linter Enhancements:

  • Added ShowSummaryOnSuccess option for both documentation and codebase linting workflows, allowing the super-linter summary to be displayed even on successful runs. Updated the workflows to post the summary conditionally based on this setting. (.github/workflows/Build-Docs.yml, .github/workflows/workflow.yml, [1] [2] [3] [4] [5]
  • Extended the settings parsing logic to support the new ShowSummaryOnSuccess option for both Build.Docs and Linter configurations. (.github/workflows/Get-Settings.yml, [1] [2]

Documentation Updates:

  • Updated README.md to document the new ShowSummaryOnSuccess options for both documentation and linter workflows, including example configuration and explanation of its usage. (README.md, [1] [2] [3] [4] [5]
  • Added a new section to .github/copilot-instructions.md for process-related Copilot instructions.

Prompt and Command Improvements:

  • Clarified execution steps in .github/prompts/pr.prompt.md to specify changing directory to the root of the attached git folder, and updated references to GitHub MCP tool commands to use simplified names. [1] [2]

Test Script Output Improvements:

  • Changed test setup and teardown scripts (BeforeAll.ps1, AfterAll.ps1) in both test repositories to use Write-Warning instead of Write-Host for better visibility of important messages. (tests/srcTestRepo/tests/BeforeAll.ps1, [1] [2]; tests/srcTestRepo/tests/AfterAll.ps1, [3] [4]; tests/srcWithManifestTestRepo/tests/BeforeAll.ps1, [5]; tests/srcWithManifestTestRepo/tests/AfterAll.ps1, [6]

v5.1.2

06 Oct 19:54
4fe1d90

Choose a tag to compare

🩹 [Docs]: Add suppressing output guidance to PowerShell style guidelines (#225)

The PowerShell style guidelines now include comprehensive guidance on suppressing unwanted output from commands and methods. This addition helps developers choose the most performant approach when they need to discard function or method return values.

Suppressing Output Section

A new section has been added to the PowerShell style guidelines (pwsh.instructions.md) that provides clear guidance on:

  • Using $null = for best performance - The recommended approach for suppressing output from both cmdlets and .NET method calls
  • Using [void] as an alternative - Another valid option specifically for method calls that return values
  • Avoiding | Out-Null - Explicitly noting that this approach has significantly slower performance and should be avoided

The section includes practical examples showing both correct and incorrect usage patterns, making it easy for developers to follow the best practices.

Performance Impact

This guidance is especially important in performance-critical code and loops, where the overhead of | Out-Null can accumulate and cause noticeable slowdowns. By using $null = or [void], developers can ensure their scripts run efficiently.

v5.1.1

06 Oct 13:35
23e6f84

Choose a tag to compare

🩹[Patch]: Test issue with break on :q! (#220)

Description

This pull request makes a minor documentation update to the Set-PSModuleTest.ps1 script by adding a .NOTES section with author, date, and version information.

#219

v5.1.0

05 Oct 19:53
9097aa2

Choose a tag to compare

🚀 [Feature]: Add settings control of repository linter (#218)

The workflow now provides fine-grained control over repository linting behavior through simple configuration options. You can disable the linter entirely or customize which validations run by configuring super-linter environment variables directly in your settings file, giving you full control over code quality checks without modifying workflow files.

Linter Configuration

Added two new settings to control repository linting behavior:

  • Linter.Skip: Completely disable repository linting when set to true
  • Linter.env: Configure super-linter environment variables to customize which validations run

What you need to do: Add these settings to your .github/PSModule.yml file as needed.

Disable the linter completely

Linter:
  Skip: true

Customize specific validations

Linter:
  env:
    VALIDATE_BIOME_FORMAT: false
    VALIDATE_JSCPD: false
    VALIDATE_JSON_PRETTIER: false

Advanced configuration

Linter:
  env:
    LOG_LEVEL: DEBUG
    FILTER_REGEX_EXCLUDE: '.*test.*'

See the super-linter environment variables documentation for all available options.

v5.0.1

03 Oct 19:37
e211007

Choose a tag to compare

🩹[Patch]: Pin super-linter actions and refine Dependabot configuration (#207)

Description

This pull request makes several updates to the GitHub Actions workflows and Dependabot configuration to improve reliability, clarity, and control over code linting and dependency management. The main changes involve pinning the super-linter action to a specific commit for reproducibility, updating linting environment variables, and enhancing dependency labeling.

GitHub Actions workflow improvements

  • Pin the super-linter/super-linter and super-linter/super-linter/slim actions to the specific commit 7bba2eeb89d01dc9bfd93c497477a57e72c83240 (v8.2.0) in all workflows, instead of using the latest tag, to ensure consistent and reproducible builds. [1] [2] [3]
  • Update linting environment variables in all workflows to explicitly disable VALIDATE_BIOME_LINT and VALIDATE_GITHUB_ACTIONS_ZIZMOR, providing finer control over which linters are run. [1] [2] [3]

Dependabot configuration enhancement

  • Add dependencies and github-actions labels to Dependabot PRs for GitHub Actions, making it easier to categorize and filter dependency updates. (.github/dependabot.yml)

PSModule process diagram

  • Updated the diagram with the repo linter.

v5.0.0

03 Oct 12:14
ee6798e

Choose a tag to compare

🌟 [Major]: Process-PSModule v5 (#205)

This pull request cleans up and consolidates the process into focussing on a single workflow, the workflow.yml file. It also updates some more logic and addresses some security issues for the checkout action.

Details

  • Removed the workflow CI.yml which has previously been used for nightly runs, checking that the logic works.

    • Mitigation: Adjusted workflow.yml to work for the same scenarios replacing CI.yml for this usecase.
    • Fixes #204
  • Cleaned up some of the job flow depending on the different scenarios.

    Job Open/Updated PR Merged PR Abandoned PR Manual Run
    Get-Settings ✅ Always ✅ Always ✅ Always ✅ Always
    Lint-Repository ✅ Yes ❌ No ❌ No ❌ No
    Build-Module ✅ Yes ✅ Yes ❌ No ✅ Yes
    Build-Docs ✅ Yes ✅ Yes ❌ No ✅ Yes
    Build-Site ✅ Yes ✅ Yes ❌ No ✅ Yes
    Test-SourceCode ✅ Yes ✅ Yes ❌ No ✅ Yes
    Lint-SourceCode ✅ Yes ✅ Yes ❌ No ✅ Yes
    Test-Module ✅ Yes ✅ Yes ❌ No ✅ Yes
    BeforeAll-ModuleLocal ✅ Yes ✅ Yes ❌ No ✅ Yes
    Test-ModuleLocal ✅ Yes ✅ Yes ❌ No ✅ Yes
    AfterAll-ModuleLocal ✅ Yes ✅ Yes ❌ No ✅ Yes
    Get-TestResults ✅ Yes ✅ Yes ❌ No ✅ Yes
    Get-CodeCoverage ✅ Yes ✅ Yes ❌ No ✅ Yes
    Publish-Site ❌ No ✅ Yes (only) ❌ No ❌ No
    Publish-Module ✅ Yes* ✅ Yes* ✅ Yes ✅ Yes*
    • Only run linter on CI runs.
    • Fast forward to "Publish-Module", which also handles removal of prereleases (GitHub only).
    • Only run "Publish-Site" on a merged PR.

v4.1.5

02 Oct 21:32
5726f53

Choose a tag to compare

Update implement prompt to update PR (#203)

Description

This pull request updates the implementation instructions in .github/prompts/implement.prompt.md to improve task tracking and clarify how pull request descriptions should be managed. The main focus is on making task progress more visible in real-time and ensuring the PR description is always ready to be used as release notes.

Task tracking and status updates:

  • Added a critical requirement to update task status immediately after each task is completed:
    • Mark the task as [X] in tasks.md and update the PR description checkbox for each completed task.
    • Updates must be made task-by-task, not at the end.
    • Provided guidance for using GitHub tools or gh pr edit to update the PR description, ensuring real-time visibility of task progress.

Pull request description management:

  • Changed instructions to require replacing the entire PR description with release notes:
    • The existing PR description, including the task list, must be cleared and replaced with release notes.
    • This ensures the PR description is immediately ready to be used as GitHub Release notes upon merging.
  • Updated the example command to clarify that the PR description should be replaced with release notes.

Type of change

  • 📖 [Docs]
  • 🪲 [Fix]
  • 🩹 [Patch]
  • ⚠️ [Security fix]
  • 🚀 [Feature]
  • 🌟 [Breaking change]

Checklist

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas

v4.1.4

02 Oct 13:07
b0c44ad

Choose a tag to compare

Updating some div stuff with specify (#200)

Description

This pull request updates and clarifies the workflow instructions for planning and implementing features, with a strong focus on correct GitHub label management, improved documentation standards, and enhanced PR/release note formatting. The changes ensure that contributors follow standardized processes for labeling, documentation, and communication, making the workflow more consistent and user-friendly.

Workflow and Label Management Improvements:

  • Both .github/prompts/plan.prompt.md and .github/prompts/implement.prompt.md now require setting and updating GitHub labels (like Planning, Implementing, Specification) at the start of each workflow, with clear instructions for both forked and local repositories. Fallback gh CLI commands are provided for manual updates. [1] [2] [3] [4]
  • The implementation workflow now includes immediate label transitions (e.g., removing Planning and adding Implementing), and the planning workflow adds/removes Planning and Specification as appropriate. [1] [2]

Documentation and Formatting Standards:

  • Added a new section in .github/instructions/md.instructions.md specifying that all requirement numbers (e.g., NFR-001, FR-042) must be formatted in bold and use non-breaking hyphens to prevent line breaks and ensure consistency in all documentation.
  • .github/copilot-instructions.md now mandates that all terminal commands in documentation be prefixed with pwsh (except for GitHub MCP calls), with examples provided for clarity.

PR and Release Note Guidance:

  • The instructions for PR descriptions have been rewritten to require a user-focused, release-note style summary, with explicit sections for "What's Changed," "Usage," "Breaking Changes," and "Technical Notes." Example command-line instructions for updating PR descriptions are included.
  • The planning workflow now requires PRs to include both a version/change-level label (e.g., Major, Minor, Patch) and a phase label (Planning), with fallback CLI commands for label management. [1] [2]

Workflow Step Clarifications and Reordering:

  • Both planning and implementation prompts have been restructured and renumbered for clarity, with explicit instructions for each step, including constitution and changelog updates, commit message standards, and final PR/issue updates. [1] [2] [3]

Changelog and Constitution Updates:

  • The implementation workflow now explicitly requires updating both the constitution and the changelog with each feature or change, following best practices for documentation and release management.

These changes collectively enforce best practices for workflow automation, documentation, and communication in the repository, improving clarity and consistency for all contributors.

Type of change

  • 📖 [Docs]
  • 🪲 [Fix]
  • 🩹 [Patch]
  • ⚠️ [Security fix]
  • 🚀 [Feature]
  • 🌟 [Breaking change]

Checklist

  • I have performed a self-review of my own code
  • I have commented my code, particularly in hard-to-understand areas