Publish a GitHub release from the changelog section - #144
Merged
Conversation
Pushing to release published packages and stopped there - no tag, no GitHub release. CLAUDE.md lists creating one as step 7 of the process, by hand, and it has not happened since v10.9.0: 10.10.0.0, 10.11.0.0, 10.11.1.0 and 10.12.0.0 all shipped to nuget.org without either. A manual step that is skipped four times running is a step that wants automating. The notes are the CHANGES.md section for the version in Xrpl.csproj, read from the "## <version> <date>" heading to the next heading. Two details worth stating, because both are deliberate: Resolving the version and extracting the notes happens BEFORE the build, not next to the release step where it would read more naturally. A changelog still titled "Unreleased" then fails the run while nothing has been published, rather than after the push to nuget.org - which cannot be taken back, and whose version number cannot be reused. That case nearly happened on 11.0.0.0. Tags follow NuGet's own normalisation, so 11.0.0.0 becomes v11.0.0, matching both the published package and the v10.9.0 / v10.8.0 tags made by hand. A fourth component that is not zero is kept, because then it carries meaning. The release step runs last, so a release only appears for packages that actually shipped, and skips an existing tag instead of failing - the pushes above are already idempotent through --skip-duplicate, and a re-run should be able to finish. Release bodies are capped at 125000 characters by GitHub and this changelog runs long - 11.0.0.0 came to 98638. Over the limit it is truncated with a pointer to CHANGES.md rather than failing the release. Needs contents: write, which the workflow did not have.
…aped traps Self-review of the step added in the previous commit. The version came from `sed ... | head -1` under `set -o pipefail`. That works only while Xrpl.csproj holds a single <PackageVersion> - there is exactly one today, so sed finishes before head closes the pipe. Add a second one and sed takes a SIGPIPE, the pipeline reports 141, and the release stops for a reason that reads like anything but the truth. awk takes the first match and exits. Truncation used head -c. These notes carry non-ASCII characters, so a byte cut can land inside one and hand the API a body that is not valid UTF-8 - a failure in the path taken least often and understood slowest. Now trimmed by whole lines, with LC_ALL=C so awk's length() counts bytes, which is the unit the cap is expressed in. Checked: a 50000-byte budget yields 49082 bytes over 185 lines, and the result decodes as UTF-8.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes the gap noticed after 11.0.0.0 went out: packages appeared on nuget.org, nothing appeared under Releases.
It was never automated
Worth saying plainly, because the assumption going in was that this had existed and was lost in a migration. It had not:
gh release create,actions/create-releaseandsoftprops/action-gh-releasereturn nothing across the whole history of.github/NugetPublish.ymldid not either — same steps, ending at the nuget.org pushv10.8.0andv10.9.0were both created by hand (authorPlatonenkovon both)CLAUDE.mdlists it as step 7 of the release process, manual. It has been skipped for 10.10.0.0, 10.11.0.0, 10.11.1.0 and 10.12.0.0 — four releases in a row, which is what makes it worth automating rather than remembering.What it does
Notes come from the
CHANGES.mdsection matching<PackageVersion>inXrpl.csproj, taken from the## <version> <date>heading to the next heading.The check runs before the build, not next to the release step. A changelog still titled
## Unreleasedfails the run while nothing has been published — rather than after the push to nuget.org, which cannot be undone and whose version number cannot be reused. That is not hypothetical: 11.0.0.0 reached a promotion PR with the heading unstamped, and it was caught by eye.Tags follow NuGet's normalisation, so
11.0.0.0→v11.0.0— matching both the published package and the hand-madev10.9.0/v10.8.0. A non-zero fourth component is kept.The release step runs last so a release only appears for packages that actually shipped, and skips an existing tag rather than failing, since the pushes above are already idempotent via
--skip-duplicate.Long notes are truncated, not fatal. GitHub caps bodies at 125000 characters; 11.0.0.0 came to 98638, so the headroom is thinner than it looks. Over the limit it truncates with a pointer to
CHANGES.md.Permissions go from
contents: readtocontents: write. Nothing else in the file changed — the diff removes exactly one line.Checked
actionlint— cleansteps.notes/steps.nuget-loginreferences verified11.0.0.0,10.11.1.0,10.9.0.0v11.0.0,v10.11.1,v10.9.012.1.3.7(non-zero fourth)v12.1.3.7, kept whole11.0.10.0v11.0.10— the0in10survives##heading## Unreleased11.0.0against## 11.0.0.0( |$)boundary holdsNot in scope
The already-shipped 11.0.0.0 still has no release: this workflow only fires on a push to
release, and that push has happened. It can be created as a one-off from the same changelog section — say the word and I will, or it can wait for the next release to prove the automation on real input.Release titles are just the tag.
v10.9.0 — Unified hex helpershad a subtitle a human wrote, and nothing here can invent one; the title is editable after the fact.