Due to a long-standing issue with `semantic-release` not checking if
`#...` reference is for a Discussion or Issue, if a contributor says
`Closes #<discussion>`, then our release process fails.
We can extend our existing checks to try and catch this in the PR
itself, as users may not read the big warning that says "don't add a
Discussion here".
Co-authored-by: Claude Sonnet 5 <jamie.tanna+claude-code@mend.io>
Renovate 44.0.0 was incorrectly released from #44004 due to the
`BREAKING ...` reference in the commit message.
Renovate uses Squash Merge as our method for merging commits into
`main`, and when enabled with the Merge Queue[0], this doesn't provide
maintainers with the ability to inspect the commit messages before
merging (which would be the case if not using the Merge Queue, we would
likely rewrite the commit message prior to merge.
With this in mind, Renovate maintainers often don't inspect the commit
messages, allowing them to stay as they are, as they'll be squashed into
the final commit.
In the case of #44004, this led to us missing the `BREAKING ...`
trailing message - from changes that were split into #44939 - and
because of this, semantic-release published this as a major release.
As a means to prevent this happening again, we can introduce a CI check
that performs a full `semantic-release --dry-run` programatically, so we
can avoid relying on log lines from `semantic-release`.
This then flags if there is a suggested major release, and if so,
rejecting it.
Co-authored-by: Claude Opus 4.8 (1M context) <jamie.tanna+claude-code@mend.io>
* ci: lint commit messages for `Closes` actions
We periodically (accidentally) merge PRs where the commit message from
the author contains a `Closes` message in them.
Although this is technically OK, we prefer to close the Issues as part
of the PR's description / with the Development tab.
When Semantic Release looks up what issue(s) are closed for a given
commit, it will look up any `Closes #...` patterns.
Sometimes these `Closes` actions are set to a Discussion number, which
Semantic Release does not support, so the post-release announcement
fails.
To prevent this happening, we can catch this on PRs by checking commits
for the known pattern for `Closes ...`.
However, because we also don't want users to close issues from their
commits anyway, we can instead enforce this across any `Closes #`
messages.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
* ci: add more closing keywords
We see `Fixes #...` every so often, too.
These are suggested by Claude Sonnet 4.5.
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
* ci: support `closes: #...` syntax
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
---------
Co-authored-by: Claude Sonnet 4.5 <jamie.tanna+github-copilot@mend.io>
Jamie Tanna