fix: accept the bare generated title as a release merge subject#8
Conversation
GitHub's 'Default to pull request title' squash setting produces a merge subject without the ' (#N)' suffix. The extraction from PodNotes lost its 2.18.1-era fix (b2a1ea6) that accepted both generated forms, so the first real consumer release (PodNotes 2.19.3, PR #291) failed post-merge validation. Restore parity: bare title or title-with-suffix, nothing else.
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 629d38eea3
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // GitHub's "Default to pull request title" squash setting omits the | ||
| // " (#N)" suffix; both subjects are generated, so both are accepted. | ||
| const mergeSubject = releaseCommit.data.message.split('\n', 1)[0]; | ||
| if (mergeSubject !== title && mergeSubject !== `${title} (#${pullNumber})`) { |
There was a problem hiding this comment.
When a consumer repo has Rebase and merge enabled and the generated release PR still contains its normal single commit on the recorded base, the rebased commit has first line title, one parent baseSha, and the same tree as the validated head, so this relaxed subject check now lets a non-squash merge proceed through validation and dispatch. The resolver in .github/workflows/release.yml duplicates the same predicate, so both sites need an additional guard to distinguish the bare squash title from the original/rebased generated commit message.
Useful? React with 👍 / 👎.
1 participant
GitHub's "Default to pull request title" squash setting produces a merge subject without the
(#N)suffix. The extraction from PodNotes lost its 2.18.1-era fix (chhoumann/PodNotes@b2a1ea6) accepting both generated forms, so the first real consumer release (PodNotes 2.19.3, PR chhoumann/PodNotes#291) failed post-merge validation withmerge commit message is invalid- after the maintainer had already merged.Both check sites patched (release-validate.yml inline forensics and release.yml's re-validation). Accepted subjects are exactly the two generated forms:
<title>and<title> (#N).45/45 tests. This is also a live instance of #6 (duplicated semantics between the two inline scripts - one more reason to consolidate).