Repository navigation
Fix Plan job failure when a module repository has no releases yet #434
Description
A new module repository created from PSModule/Template-PSModule has no GitHub releases yet. The first pull request opened in such a repository fails in the Plan job before any build, test, or lint stage runs, so a maintainer bootstrapping a module cannot get a green pipeline on the pull request that is supposed to produce the first release.
Request
What happens
The Plan / Resolve-Version step fails with:
Cannot bind argument to parameter 'Releases' because it is null.
Every downstream job is skipped, so the pull request reports a failed pipeline with no way for the contributor to act on it. The failure is not caused by anything in the module being bootstrapped — it happens on a repository whose src/ builds and tests cleanly.
Reproduction steps
- Create a repository from
Template-PSModuleand do not publish any release or tag - Open a pull request against
main - Observe that
Process-PSModule / Plan / Planfails and every other job is skipped
What is expected
The pipeline treats "no releases yet" as the normal starting state of a module. Version resolution floors at 0.0.0, applies the pull request's release label on top of it, and the rest of the pipeline runs as it would for any other pull request.
Environment
- Workflow version:
PSModule/Process-PSModule/.github/workflows/workflow.yml@v6.1.13and@v6.1.14 - Repository state: zero releases, zero tags
- Observed in: PSModule/Lovdata#3
Regression
Not verified against earlier workflow versions. The affected code moved into the workflow repository in #385, so it is reachable in every version that internalizes the actions.
Workaround
Publish a placeholder GitHub release, for example v0.0.0, before opening the first pull request, so the release list is not empty. It has to be cleaned up afterwards and pollutes the release history of a module that has never shipped.
Acceptance criteria
- The first pull request in a repository with no releases completes the
Planjob and runs the rest of the pipeline - Version resolution starts from
0.0.0when no release exists, and the pull request's release label bumps from there - Behaviour for repositories that already have releases is unchanged
Technical decisions
Root cause: Get-GitHubRelease in .github/actions/Resolve-PSModuleVersion/src/Resolve-PSModuleVersion.Helpers.psm1 runs gh release list --json ..., which returns [] for a repository with no releases. '[]' | ConvertFrom-Json emits nothing, so an empty pipeline collapses to $null and the function returns $null rather than an empty array. Get-LatestGitHubVersion and Get-NextModuleVersion both declare [Parameter(Mandatory)] [array] $Releases, and a mandatory parameter rejects $null at binding time.
Fix placement: Guard at both ends rather than only one. The producer (Get-GitHubRelease) is made to return an array consistently, and the consumers accept an empty one. Fixing only the producer leaves the same trap for any future caller that passes an empty collection.
Producer change: Get-GitHubRelease declares [OutputType([array])] already; wrap its result so an empty release list is returned as an empty array instead of nothing, and wrap the call site in main.ps1 with @(...) so the array is preserved across the assignment.
Consumer change: Add [AllowEmptyCollection()] to the Releases parameter of Get-LatestGitHubVersion and Get-NextModuleVersion. Both already handle an empty list correctly — Get-LatestGitHubVersion warns and falls back to 0.0.0, and the incremental prerelease lookup finds no matching tags — so only the binding needs to change.
Breaking changes: None. Repositories that already have releases bind a non-empty array exactly as before.
Test approach: The helper module has no test coverage today, and adding a test harness for it is a larger change than this fix. The change is verified against a real bootstrapping repository with zero releases.
Implementation plan
Core changes
- Return an empty array from
Get-GitHubReleasewhen the repository has no releases - Wrap the
Get-GitHubReleasecall inmain.ps1so the empty array survives assignment - Add
[AllowEmptyCollection()]to theReleasesparameter ofGet-LatestGitHubVersion - Add
[AllowEmptyCollection()]to theReleasesparameter ofGet-NextModuleVersion
Verification
- Confirm the
Planjob completes on a pull request in a repository with no releases - Confirm version resolution still works in a repository that has releases
Activity
Point CI at the empty-release-list fix branch for validation
MariusStorhaug commentedon Aug 2, 2026
Duplicate of #381, which reported the same
Planfailure three weeks earlier and is being fixed by #432. Closing in favour of those; the reproduction from a brand-new repository is recorded on #381 and #432.Carrying over the one detail worth keeping from this write-up:
[Parameter(Mandatory)] [array]rejects an empty collection as well as$null, so normalising the call site alone is not enough. #432 already handles that.The end-to-end confirmation is on #435: with the fix applied, PSModule/Lovdata#3 ran the full pipeline green on Linux, macOS, and Windows from a repository with zero releases, resolving
v1.0.0from themajorlabel.