Skip to content

Releases: PSModule/Resolve-PSModuleVersion

v1.0.0

22 May 23:13
3237617

Choose a tag to compare

🌟 [Major]: Module version resolution now available as a standalone action (#1)

Module version resolution is now available as a standalone action. Workflows can call it before building so the resolved version is stamped into the artifact at build time, making the bytes that are tested the bytes that ship.

New: Standalone Resolve-PSModuleVersion action

The action consumes the JSON Settings output from PSModule/Get-PSModuleSettings and emits:

Output Description
Version Major.Minor.Patch portion of the resolved version.
Prerelease Prerelease tag, empty when not a prerelease.
FullVersion Full version string including VersionPrefix and prerelease tag.
ReleaseType Release, Prerelease, or None when no version bump label is present.
CreateRelease true when a release or prerelease should be created.

Typical usage in the Plan job:

- name: Resolve module version
  id: resolve
  uses: PSModule/Resolve-PSModuleVersion@v1
  env:
    GH_TOKEN: ${{ github.token }}
  with:
    Settings: ${{ steps.settings.outputs.Settings }}

- name: Build module
  uses: PSModule/Build-PSModule@v5
  with:
    Version: ${{ steps.resolve.outputs.Version }}
    Prerelease: ${{ steps.resolve.outputs.Prerelease }}

The action validates Settings.Publish.Module.ReleaseType, applies IgnoreLabels overrides, picks the bump type from PR labels (MajorLabels > MinorLabels > PatchLabels / AutoPatching), then computes the next version from the higher of the latest GitHub Release and the latest PowerShell Gallery version. For prereleases it appends the sanitized branch name, optional DatePrereleaseFormat timestamp, and an incremental counter calculated from existing prereleases on the same baseline + branch.

Technical Details

  • action.yml: composite action with inputs Settings (required JSON), Name, WorkingDirectory, Debug, Verbose, Version, Prerelease, plus EventPath and EventJson (both optional, for test overrides — EventJson takes precedence over reading the file at EventPath). All ${{ }} template expressions are isolated in env: sections per zizmor template-injection requirements. Installs PSModule/Install-PSModuleHelpers and PSSemVer before running the script.
  • scripts/main.ps1: ports the version-resolution logic that previously lived in Publish-PSModule/src/init.ps1. Reads configuration from PSMODULE_RESOLVE_PSMODULEVERSION_INPUT_Settings JSON instead of separate env vars. Reads the PR event from PSMODULE_RESOLVE_PSMODULEVERSION_INPUT_EventJson when set, falling back to the file at GITHUB_EVENT_PATH. Emits outputs via $env:GITHUB_OUTPUT. Cleanup-tag discovery stays in Publish-PSModule/cleanup.ps1 and is intentionally out of scope here.
  • .github/workflows/Action-Test.yml: 6 test jobs covering patch, minor, major, auto-patch, ignore-label, and None scenarios. The ignore-label job passes the fake PR event as a JSON string via EventJson to bypass the runner's real event file, which cannot be reliably overridden at the file-system level.
  • README.md: replaces the template scaffold with the action's contract and usage examples.

Implementation plan progress (PSModule/Process-PSModule#326):

  • ✅ Create Resolve-PSModuleVersion (LICENSE, README, action.yml, scripts/main.ps1, Action-Test workflow)
  • ✅ Inputs: Settings, Name, WorkingDirectory (plus EventPath/EventJson for test overrides)
  • ✅ Outputs: Version, Prerelease, FullVersion, ReleaseType, CreateRelease
  • ✅ Port version-resolution logic from Publish-PSModule/src/init.ps1 (PSSemVer install, GitHub Releases query, PSGallery query, PR-label parsing, bump selection, prerelease sequencing, DatePrereleaseFormat, VersionPrefix)
  • ⬜ Dedicated Pester unit tests for label parsing, bump selection, and prerelease sequencing — covered by the six integration test jobs; a focused unit-test suite remains open

Related PRs: