Skip to content

Label a one-package release with its version, not its last character - #54

Merged
jwrosewell merged 3 commits into
rcfrom
fix/one-package-label
Nov 13, 2026
Merged

jwrosewell merged 3 commits into
rcfrom
fix/one-package-label

Conversation

@jwrosewell

@jwrosewell jwrosewell commented Nov 7, 2026 •

Copy link
Copy Markdown
Contributor

Problem

ci/get-next-package-version.ps1 line 16 on rc labels a publish with the highest version in the release plan.

$label = ($plan.Version | Sort-Object { [version]$_ })[-1]

When the plan holds one package, $plan.Version and the sort give back that one version as a string, not as an array of one, and [-1] then takes the string's last character. A plan that releases one package at 4.5.3 gives the run the label 3, which the publish's version check refuses. So the first release in which only one package changes would fail to publish. With the release plan now leaving out documentation, tests and examples (#60), a release of one package is more likely.

Change

The sort is collected with the array subexpression operator @() before the last item is taken, as ci/packages.ps1 line 311 already does. The PowerShell operators reference says of @( ), "Returns the result of one or more statements as an array. The result is always an array of 0 or more objects."

The other indexing in the CI scripts reads [version] objects rather than strings, and PowerShell gives a single object back for [-1], so only this line changes.

ci/get-next-package-version.Tests.ps1 is new. It runs the script beside a stand-in packages.ps1 whose release plan is the versions each test gives, and checks the label for one package, for several, and for none.

Checks

No workflow in this repository runs the Pester tests in ci/, so each run below is a temporary branch holding a workflow that runs every ci/*.Tests.ps1 with Pester on ubuntu-latest and windows-latest, and then prints the release plan of the branch.

  • Red, rc at df0949d7 with the new test and without the fix, run 43474381584, failed on both. Tests Passed: 132, Failed: 1, the failure being labels a plan of one package with its whole version.
  • Green, this head with the same workflow, run 43474406652, passed on both. Tests Passed: 133, Failed: 0.

This draft changes only CI scripts and their tests, with no package code. James Rosewell decided at about 11:35 UTC on 12 November, for such a change, "rebuild and include, but the change doesn't impact the code so no need to run the full builds." So it has no full build of its own, and its pull request checks are its quick checks. All three passed on this head, being run 43474367014 (environment variable names), run 43474367564 (only rc into main) and run 43474367167 (link campaign tags).

Head bcbb12fe is the earlier fix with rc at df0949d merged in. The last release into main was #114, merged at 06:22 UTC on 13 November.

What remains

Nothing in this draft. No workflow runs the tests in ci/, as #47 and #60 also note.

When the release plan holds one package, $plan.Version is a single string,
Sort-Object hands it back as a string, and [-1] took its last character, so
a plan releasing 4.5.3 alone gave the run the label 3, which the publish's
version check refuses. The sort is now collected into an array first.
@jwrosewell
jwrosewell marked this pull request as ready for review November 13, 2026 19:10
@jwrosewell
jwrosewell merged commit d7480ee into rc Nov 13, 2026
3 checks passed
@jwrosewell
jwrosewell deleted the fix/one-package-label branch November 13, 2026 19:10
jwrosewell added a commit that referenced this pull request Nov 14, 2026
The scripts in `ci/` decide what a pull request builds and what a publish releases, and each has Pester tests beside it. `rc` holds five such files, being `ci/packages.Tests.ps1`, `ci/dispatch.Tests.ps1`, `ci/check-environment-variable-names.Tests.ps1`, `ci/get-next-package-version.Tests.ps1` from [#54](#54) and `ci/select-options.Tests.ps1` from [#33](#33). Only the environment variable name tests ran in a workflow. The rest ran only by hand or on a temporary branch, as [#47](#47), [#54](#54) and [#60](#60) each say under what remains, so a change to the release plan or the dispatcher could break them unseen.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant