chore(master): release 8.1.0 - #279
Merged
sidorares merged 1 commit intoAug 18, 2026
Merged
Conversation
github-actions
Bot
force-pushed
the
release-please--branches--master--components--ntk
branch
2 times, most recently
from
August 18, 2026 04:34
e3d70a6 to
b505519
Compare
sidorares
added a commit
that referenced
this pull request
Aug 18, 2026
…en (#281) #278 merged and release-please skipped it. The Release workflow went green, logged `commits: 3` for four commits since v8.0.0, and left the release PR untouched — no shadows entry in 8.1.0's changelog. The run says why: ``` ❯ commit could not be parsed: 6eba5a7 feat(context2d): shadows, ... (#278) ❯ error message: Error: unexpected token '\n' at 24:73, valid tokens [)] ❯ commits: 3 ✔ PR #279 remained the same ``` Line 24 of the squash commit is the screenshot caption, and column 73 is its end: the line stops after `captured headless`, with the next one starting at `into a pixmap`. The caption's opening bracket is left unclosed at the newline, and the grammar rejects that. In the PR description the same caption is a single 106-character line, whole and balanced. Squash-merge wraps the body at 72 columns on its way to becoming a commit, and the wrap is what splits it. I cannot quote the two lines here as they appear in the commit: this description is checked by the very rule it is about, and quoting them would fail the check. That is the failure mode, exactly. ## Why the guard missed it `release-message` passed on #278. It composes `MESSAGE` from `pull_request.title` and `pull_request.body` and parses that — the text before the transformation that breaks it. Verified in both directions against the real message: | input | longest line | guard, before this branch | | --- | --- | --- | | title + body, as CI composed it | 526 | `parses: type=feat` | | the same text wrapped at 72 | 72 | fails at the caption | | the real squash commit `6eba5a7` | 91 | fails, `24:73` | So the miss is not about nested parentheses, the failure mode the guard was written for after #85 and #103. It is a second, independent way in: any parenthetical long enough to be wrapped, which is a property of length rather than of nesting. ## What changed - **The message is parsed twice**, as written and as the squash will write it. When only the second fails, the error says so, because the line it names looks fine in the PR. - **`wrapLikeSquash` is the emulation**: the subject is left alone, body lines are word-wrapped at 72 columns, and a token wider than the margin keeps its own line rather than being split. Close to GitHub's wrapping rather than byte-identical to it, which is all the guard needs. - **`.github/workflows/ci.yml` is unchanged** — the job already passed the right text. The script simply stops trusting it. Run against the exact title and body CI had for #278, the guard now exits 1: ``` release-please could not parse this commit message. unexpected token ' This is the message *as the squash commit will hold it* — the body wrapped at 72 columns. It parses as written, which is why the line below may look fine in the PR: the wrap is what splits it. 23 | ...the caption line, elided here for the reason above... | ^ ``` ## Tests New `test/release-message.test.js`, 8 cases: the wrapper's three rules, #278's caption parsing as written and failing once wrapped, the guard's exit code and its explanation, #103's nested call, and a passing feat plus a chore for the no-bump branch. Both failure cases use the **real** lines. My first draft of the #103 case used an invented nested call in a plain sentence, and it parsed; the real line, the same call inside backticks, does not. Whether the grammar trips depends on the surroundings, which is the argument for running the parser rather than grepping for parentheses. Full suite green locally against XQuartz, apart from the usual two that need a server this machine does not have: `glx` wants `+iglx` and `xi2-live` wants pointer warps to deliver motion. ## Still outstanding The changelog entry for #278 itself. 8.1.0 is already a minor bump so the version is unaffected, but the line is missing, and an empty commit on master is what restores it — as it did for #85 and #103.
github-actions
Bot
force-pushed
the
release-please--branches--master--components--ntk
branch
from
August 18, 2026 05:06
b505519 to
18f9bd1
Compare
sidorares
deleted the
release-please--branches--master--components--ntk
branch
August 18, 2026 05:11
Contributor
Author
|
🤖 Created releases: 🌻 |
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.
🤖 I have created a release beep boop
8.1.0 (2026-08-18)
Features
Bug Fixes
This PR was generated with Release Please. See documentation.