What happened
comfyui-model-gallery#53 merged a feat to main. release-please ran, exited
green, and created no release PR. The feature sat unreleased with no
failure anywhere.
The run log gives the cause: the commit could not be parsed, with an "unexpected
token at 18:22" error whose only valid token was a closing paren, then
"Considering: 0 commits" and "No commits for path, skipping".
Why
All these repos set squash_merge_commit_message = PR_BODY, so the PR
description becomes the squash commit body. #53's description contained a
fenced TypeScript block, and line 18 column 22 of that body landed on the
opening brace-paren of a function call — an unbalanced paren before a newline.
release-please's conventional-commit parser threw on the whole commit, so the
only releasable commit in the range was discarded.
Confirmed by the control: comfyui-prompt-editor#69 has an equally long
description and released fine, purely because its final version happened to
carry no code fence.
Why it deserves a guard rather than a habit
The failure is a non-event. The workflow is green, no annotation is emitted,
and the symptom is the absence of a release PR — which looks identical to
"nothing releasable landed". It surfaced here only because someone was watching
for a specific version to publish. Any repo in the portfolio with a code fence
in a PR description is exposed, and "remember not to put code blocks in PR
bodies" is not a workable rule for humans or agents.
Options, roughly cheapest first
- A CI check on the release-please run that fails, or posts a warning, when
release-please reports zero considered commits while the pushed range contains
a commit whose subject matches the conventional-commit prefix set. This
catches the whole class regardless of the specific parser quirk.
- Switch
squash_merge_commit_message to COMMIT_MESSAGES for the
release-please-managed repos, so the squash body is the authored commit
message rather than the PR description. Commit messages are written with this
in mind; PR descriptions are written for humans and routinely contain code.
Managed in gitops/repositories.tf, so it is a one-line change per repo.
- A PR-body linter rejecting fenced blocks. Cheapest to implement, worst
trade — PR descriptions should be able to show code.
Option 2 addresses the root cause and option 1 catches the residue; they compose.
Repro / evidence
- Broken: comfyui-model-gallery#53, its post-merge release-please run, and the
absent release PR.
- Recovery: comfyui-model-gallery#54 — a fence-free PR restating the subject,
which released as comfyui-model-gallery-v0.1.17.
- Control: comfyui-prompt-editor#69, released as
comfyui-prompt-editor-v0.1.23.
What happened
comfyui-model-gallery#53 merged a
feattomain. release-please ran, exitedgreen, and created no release PR. The feature sat unreleased with no
failure anywhere.
The run log gives the cause: the commit could not be parsed, with an "unexpected
token at 18:22" error whose only valid token was a closing paren, then
"Considering: 0 commits" and "No commits for path, skipping".
Why
All these repos set
squash_merge_commit_message = PR_BODY, so the PRdescription becomes the squash commit body. #53's description contained a
fenced TypeScript block, and line 18 column 22 of that body landed on the
opening brace-paren of a function call — an unbalanced paren before a newline.
release-please's conventional-commit parser threw on the whole commit, so the
only releasable commit in the range was discarded.
Confirmed by the control: comfyui-prompt-editor#69 has an equally long
description and released fine, purely because its final version happened to
carry no code fence.
Why it deserves a guard rather than a habit
The failure is a non-event. The workflow is green, no annotation is emitted,
and the symptom is the absence of a release PR — which looks identical to
"nothing releasable landed". It surfaced here only because someone was watching
for a specific version to publish. Any repo in the portfolio with a code fence
in a PR description is exposed, and "remember not to put code blocks in PR
bodies" is not a workable rule for humans or agents.
Options, roughly cheapest first
release-please reports zero considered commits while the pushed range contains
a commit whose subject matches the conventional-commit prefix set. This
catches the whole class regardless of the specific parser quirk.
squash_merge_commit_messagetoCOMMIT_MESSAGESfor therelease-please-managed repos, so the squash body is the authored commit
message rather than the PR description. Commit messages are written with this
in mind; PR descriptions are written for humans and routinely contain code.
Managed in
gitops/repositories.tf, so it is a one-line change per repo.trade — PR descriptions should be able to show code.
Option 2 addresses the root cause and option 1 catches the residue; they compose.
Repro / evidence
absent release PR.
which released as
comfyui-model-gallery-v0.1.17.comfyui-prompt-editor-v0.1.23.