v4.0.7

Bump actions/download-artifact from 4 to 5 (#181)

Bumps actions/download-artifact from 4 to 5.

Release notes

Sourced from actions/download-artifact's releases.

v5.0.0

What's Changed

• Update README.md by @​nebuk89 in actions/download-artifact#407
• BREAKING fix: inconsistent path behavior for single artifact downloads by ID by @​GrantBirki in actions/download-artifact#416

v5.0.0

🚨 Breaking Change

This release fixes an inconsistency in path behavior for single artifact downloads by ID. If you're downloading single artifacts by ID, the output path may change.

What Changed

Previously, single artifact downloads behaved differently depending on how you specified the artifact:

• By name: name: my-artifact → extracted to path/ (direct)
• By ID: artifact-ids: 12345 → extracted to path/my-artifact/ (nested)

Now both methods are consistent:

• By name: name: my-artifact → extracted to path/ (unchanged)
• By ID: artifact-ids: 12345 → extracted to path/ (fixed - now direct)

Migration Guide

✅ No Action Needed If:

• You download artifacts by name
• You download multiple artifacts by ID
• You already use merge-multiple: true as a workaround

⚠️ Action Required If:

You download single artifacts by ID and your workflows expect the nested directory structure.

Before v5 (nested structure):

- uses: actions/download-artifact@v4
  with:
    artifact-ids: 12345
    path: dist
# Files were in: dist/my-artifact/

Where my-artifact is the name of the artifact you previously uploaded

To maintain old behavior (if needed):

</tr></table> 

... (truncated)

Commits

• 634f93c Merge pull request #416 from actions/single-artifact-id-download-path
• b19ff43 refactor: resolve download path correctly in artifact download tests (mainly ...
• e262cbe bundle dist
• bff23f9 update docs
• fff8c14 fix download path logic when downloading a single artifact by id
• 448e3f8 Merge pull request #407 from actions/nebuk89-patch-1
• 47225c4 Update README.md
• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)

v4.0.6

🪲 [Fix]: Fix issue with parameters and GitHub token access (#172)

Description

This pull request updates several GitHub Actions workflows to simplify input parameters and improve artifact handling. Key changes include the removal of unused parameters (Debug, Verbose, Version, and Prerelease) and the addition of an ArtifactName parameter for uploading artifacts. Additionally, environment variables are introduced for authentication.

Simplification of input parameters:

• .github/workflows/Build-Module.yml: Removed unused parameters (Debug, Verbose, Version, and Prerelease) and added a new ArtifactName parameter to specify the name of the artifact to upload. [1] [2]

Environment variable addition:

• .github/workflows/Build-Module.yml: Added the GH_TOKEN environment variable for authentication using GitHub's token.

Consistency across workflows:

• .github/workflows/CI.yml and .github/workflows/workflow.yml: Removed references to unused parameters (Debug, Verbose, Version, and Prerelease) to align with the updated Build-Module.yml. [1] [2]

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

🪲 [Fix]: Access to GH_TOKEN and Get-Settings for Name (#171)

Description

This pull request includes updates to the workflow files to improve clarity and functionality. The changes primarily focus on refining conditional logic in PowerShell scripts and enhancing environment variable handling in GitHub Actions.

Workflow improvements:

• .github/workflows/Get-Settings.yml: Updated the conditional logic for determining the $name variable to use explicit if-elseif-else statements, improving readability and maintainability.

Environment variable and input adjustments:

• .github/workflows/workflow.yml: Added the GH_TOKEN environment variable to the Publish module step to ensure authentication is handled securely.
• .github/workflows/workflow.yml: Reintroduced the WorkingDirectory input to the Publish module step for better modularity and flexibility in specifying paths.

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

🩹 [Patch]: Remove redundant actions (#170)

Description

This pull request simplifies the workflow configuration by removing the Initialize-PSModule step from two GitHub Actions workflows. This change reduces redundancy and streamlines the build and artifact download processes.

Workflow updates:

• .github/workflows/Build-Module.yml: Removed the Initialize-PSModule step, which previously set up the environment for building the module.
• .github/workflows/workflow.yml: Removed the Initialize-PSModule step, which was used to prepare the environment before downloading module artifacts.

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

🩹 [Patch]: Add installation of PSCustomObject on Test-ModuleLocal (#166)

Description

This pull request updates the .github/workflows/Test-ModuleLocal.yml file to optimize module loading during Pester tests by installing a required PowerShell resource.

Workflow optimization:

• .github/workflows/Test-ModuleLocal.yml: Added a step to install the PSCustomObject module from the PSGallery repository to streamline module loading in Pester.

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

Description

This pull request introduces a small but important update to the GitHub Actions workflow configuration. It ensures that the latest version of the Microsoft.PowerShell.PSResourceGet module is installed before publishing a PowerShell module.

• Fixes PSModule/NerdFonts#33

• .github/workflows/workflow.yml: Added a step to install the Microsoft.PowerShell.PSResourceGet module from the PSGallery repository using Install-PSResource.

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

Description

This pull request reverts changes to the .github/workflows/Test-ModuleLocal.yml file to restore testing capabilities and module loading performance.

Details:

• Restored the GITHUB_TOKEN environment variable mapping, allowing it to be used in tests once more.
• Restored the Prescript step to preload the module with a specific version, optimizing module loading during Pester tests.

v4.0.0

The PSModule v4 release is a major overhaul of the PowerShell module workflow, introducing significant architectural changes to improve speed, modularity, and maintainability. This update continues on the goal to split the once-monolithic process into distinct GitHub Actions for building, testing, documenting, and publishing modules. By refactoring the workflow into isolated steps and enabling parallel execution, v4 dramatically optimizes build and test times while ensuring a more reliable and customizable process for module developers.

Diagram - Old version

Features

Parallel Testing & Results Aggregation

The workflow has been reworked to support flexible, parallelizable test runs. The Test-PSModule action will now execute tests in parallel via matrix jobs (e.g. across multiple OSes or test stages). Separate helper actions (Get-PesterTestResults and Get-PesterCodeCoverage) have been introduced to aggregate Pester test outcomes and code coverage from those parallel jobs, providing unified reporting and enforcing test success and coverage thresholds across the matrix.

• Fixes #78
• Fixes #119

Central Configuration File

A new configuration hierarchy allows customizing the process through a YAML (JSON or PSD1) settings file. Users can include a .github/PSModule.yml in their module repo to override defaults. This centralized config makes the pipeline more flexible and eliminates the need for hard-coded inputs in workflow files.

• Fixes #144
• Fixes #81
• Fixes #159

Dedicated Documentation Step

Documentation generation is now handled by a new Document-PSModule action. This step automatically builds the module's documentation (using PlatyPS) and uploads as an artifact, so that other steps can build a site and publish it to GitHub Pages. By isolating documentation in its own action, v4 ensures that doc-specific tools (e.g. PlatyPS and MkDocs) run without interference from build or test modules, and documentation is kept up-to-date with each release.

• Fixes #148
• Fixes #77
• Fixes #95

Shared Helper Module Action

A new Install-PSModuleHelpers action has been introduced as a foundational setup step. It installs and configures common helper functions used by the pipeline (for example, version specification conversion, module dependency resolution, and module installation utilities). This ensures all subsequent actions operate with a consistent environment and shared logic. Common functionality like resolving module dependencies (Resolve-PSModuleDependency) and version parsing has been consolidated here, reducing duplication across the build/test/publish steps.

Enhanced Platform and Compatibility Support

The v4 workflow expands support and testing across platforms and PowerShell versions. The Test-PSModule action runs on Windows, Linux, and macOS with PowerShell Core (and includes light support for Windows PowerShell 5.1 for basic compatibility).

• Fixes #146

New test actions

Static analysis is performed via a dedicated Invoke-ScriptAnalyzer GitHub action, and Pester tests are executed in an isolated context via the Invoke-Pester GitHub action, ensuring consistent behavior across different environments and increases the reusability of the automation we built around Pester. The new design also honors repository-specific analyzer settings (automatically picking up settings from .github/linters/.powershell-psscriptanalyzer.psd1 in the repo for static code analysis), allowing module developers to customize linting rules.

• Fixes #108
• Fixes #130

Modular Workflows

By splitting the CI/CD process into discrete actions and enabling concurrency, the overall pipeline runtime is greatly reduced. Linting, unit tests, and integration tests can run in parallel, and the build step no longer blocks documentation or analysis. This time-optimized process means quicker feedback on pull requests and faster delivery of new module releases.

Simplified Build & Publish Process

The Build-PSModule action has been refactored into a pure module builder. New inputs like ArtifactName and WorkingDirectory give more control over build output naming and source path. The build step now produces a clean module package and uploads it as an artifact called module. Likewise, the Publish-PSModule action has been bumped to v2 with a clearer interface – it removes the old monolithic ConfigurationFile input in favor of explicit inputs and the new central settings file. The publish logic now uses the repository’s context (working directory defaulting to .) and respects the unified settings, simplifying how modules are published to the PowerShell Gallery.

Robust Dependency Handling

Module dependency resolution during builds is now more reliable and up-to-date. The pipeline switched to using PSResourceGet for installing required module dependencies, replacing the legacy PowerShellGet v2 approach. This change ensures compatibility with the latest PowerShell module packaging standards and improves the speed and success of acquiring dependencies. The helper scripts (Convert-VersionSpec and Resolve-PSModuleDependency) were moved into the shared helpers module, and their logic was hardened with better retry and null-check mechanisms when querying the PowerShell Gallery.

• Fixes #62

Better Logging and Diagnostics

Each action now provides more transparent logging and output for easier troubleshooting. The Publish step, for example, now logs all input parameters at the start of execution for traceability. Verbose logging in dependency resolution has been replaced with clear console output to ensure important information is always visible. The Get-PesterTestResults action prints a detailed summary of test suites executed, including counts of passed/failed/skipped tests, and will mark the workflow as failed if any tests did not run or failed – giving immediate feedback if something went wrong in the parallel test jobs.

• Fixes #91

Other smaller issues

• Fixes #82

Related actions and PRs

• Install-PSModuleHelpers | PSModule/Install-PSModuleHelpers#2
• Test-PSModule | PSModule/Test-PSModule#98
• Get-PesterTestResults | PSModule/Get-PesterTestResults#2
• Get-PesterCodeCoverage | PSModule/Get-PesterCodeCoverage#1
• Invoke-Pester
• Invoke-ScriptAnalyzer
• Document-PSModule | PSModule/Document-PSModule#16
• Build-PSModule | PSModule/Build-PSModule#108
• Publish-PSModule | PSModule/Publish-PSModule#49

v3.2.17

What's Changed

Other Changes

• 🪲 [Fix]: Fix placement of docs after copy by @MariusStorhaug in #138

Full Changelog: v3...v3.2.17

v3.2.16

What's Changed

Other Changes

• 🪲 [Fix]: Fix an issue that break the workflow when there is nothing to commit in BuildDocs by @MariusStorhaug in #137

Full Changelog: v3...v3.2.16