Release automation: publish the GitHub release for 11.0.0.0 - #145
Merged
Conversation
* ci(release): publish a GitHub release from the changelog section 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. * ci(release): resolve the version and trim notes without the two CI-shaped 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.
Carries the GitHub release automation into
release, and by running there it produces the release that 11.0.0.0 never got.No new package version
<PackageVersion>is untouched:XrplandXrpl.BinaryCodecstay at 11.0.0.0,Xrpl.AddressCodecandXrpl.Keypairsat 10.9.0.0. All of those are already on nuget.org, so every push in this run is a duplicate and--skip-duplicatewill pass over it.That is observed behaviour rather than an assumption: the previous release runs pushed the unchanged
AddressCodec10.9.0,Keypairs10.9.0 and bothX4021.0.0 packages every time, and finished green.What this run is expected to do
11.0.0.0, tagv11.0.0, 98638 characters of notesv11.0.0Anything other than a skip on the two push steps would mean
--skip-duplicateis behaving differently than in previous runs — worth knowing now rather than during a real release.One inaccuracy, accepted knowingly
The tag lands on this promotion's merge commit rather than on
736c7218, which is what 11.0.0.0 was actually built from. The SDK sources are identical between the two — the difference isnuget.release.ymlalone — so the tag marks the same code, one commit later.Not exercised
The truncation branch stays untested on real input: 98638 is under the 120000 cap. It was checked locally — a 50000-byte budget yielded 49082 bytes over 185 lines, decoding cleanly as UTF-8 — but it will not run for real until a changelog section exceeds the cap.