Commit message check does not enforce "fixes"/"refs" in parentheses

[platinumazure]

Since we no longer enforce that commits end with "fixes [issue]" or "refs [issue]", we are now allowing commit messages which do mention an issue, but not the way we would like. (See eslint/eslint#9745 for an example.)

Would it be possible to flag commit messages that do contain "fixes [issue]" or "refs [issue]", but not formatted the way we like (i.e., in parentheses at the end of the commit summary)? Is this something we should consider doing?

[platinumazure]

Friendly ping to @eslint/eslint-team for thoughts on this one.

[nzakas]

I think we should definitely do this. The more early feedback we can give to people, the better.

[kaicataldo]

Agreed! And better to automate it when we can - saves everyone time and energy.

[platinumazure]

Apologies, I've left this sitting for a while. I'm hoping to work on this in the next few weeks-- if someone else wants to work on this, just leave a comment and I'll happily leave it to you.

Here's my rough implementation idea:

• All changes go in the commit-message plugin
• First, run the commit summary through a regex looking for something like #\d+
• If found, then check that message ends with (fixes #1111) or (refs #1111)
  • Or, for multiple issues: (fixes #1111, refs #2222, fixes #3333) (basically allow list of fixes/refs issue number)
• If issue number was detected but commit message does not end properly, fail the commit-message check. Add info to the commit guidelines web page (linked in the status check).

If anyone has any feedback on this, feel free to share. Otherwise, that's what I'll attempt to do once I start working on this.