Repository navigation
ci(release): create the GitHub release after the Gallery upload - #54
Conversation
A tag published the module to the PowerShell Gallery but created no GitHub release, so the repository lists none for any published version. The other module repositories get the same job, so all of them release the same way. A github-release job now follows the publish job. It takes the module name and version from the root manifest and uses that version's CHANGELOG.md section as the release notes, with an Update-PSResource line and a link to the full history. It fails when the section is missing or empty. The notes are built in every run, a dry run included, so a missing section shows up before a tag is pushed. The release itself is created only for a tag push, with --verify-tag, and a release that already exists for the tag is left as written. The job alone has contents: write; the workflow keeps contents: read.
fadwen
left a comment
fadwen
left a comment
There was a problem hiding this comment.
Notes on the lines whose reason the diff does not show.
| for ($i = $start + 1; $i -lt $lines.Count; $i++) { | ||
| if ($lines[$i] -match '^## \[') { $end = $i; break } | ||
| } | ||
| $section = if ($end -gt $start + 1) { ($lines[($start + 1)..($end - 1)] -join "`n").Trim() } |
There was a problem hiding this comment.
The guard matters. When a version heading is followed directly by the next heading, ($start + 1)..($end - 1) counts down instead of up and picks up the next version's heading, so an empty section would have become notes holding the previous release. This is one of the cases tested locally.
| Write-Host $notes | ||
|
|
||
| - name: Create the GitHub release | ||
| if: ${{ startsWith(github.ref, 'refs/tags/') && !inputs.dryRun }} |
There was a problem hiding this comment.
This is the condition the Publish step already uses. On a tag push inputs.dryRun is empty, so !inputs.dryRun is true. A workflow_dispatch with the default dryRun: true skips the step, so a dry run never creates a release.
| run: | | ||
| $ErrorActionPreference = 'Stop' | ||
| # A release made by hand before this job ran is kept as written | ||
| gh release view $env:RELEASE_TAG *> $null |
There was a problem hiding this comment.
This check exists so re-running the job is safe. If it fails after the Gallery upload, re-running it creates the release. If a release was written by hand in the meantime, the re-run leaves that one alone instead of failing on a duplicate or overwriting it.
Summary
Pushing a version tag published the module to the PowerShell Gallery but did not create a GitHub release. The repository therefore lists no release for any of its published versions.
release.ymlnow creates one for each tag.Changes
github-releasejob afterpublish. It runs onubuntu-latestand is the only job withcontents: write; the workflow default stayscontents: read.ModuleVersionfrom the one manifest at the repository root and takes that version's## [<version>]section ofCHANGELOG.md. The notes are that section, anUpdate-PSResource <Module>block above it, and a link to the full CHANGELOG at the tag below it. A missing or empty section fails the job. Dry runs build the notes too, so the CHANGELOG is checked before a tag exists.gh release create v<version> --verify-tagruns only for a tag push, never for a dry run. A release that already exists for the tag, such as one written by hand, is left unchanged. GitHub decides which release is Latest by version, so a later patch to an older line does not take over the label.CLAUDE.md: the release section now describes the new step and the CHANGELOG section it depends on.Verification
GitHub releasejob built the 0.34.0 notes (2,448 characters) and skipped the create step.mainCHANGELOG and manifest of each module repository, this one included. Each produced its latest version's notes.## [1.1.0.1]for1.1.0.gh release viewandgh release create, the same ones used for the hand-made releases.Notes