How should I deal with merged PRs that append an issue number, past 72 characters?

I like the default header-max-length rule. Having a short commit message makes concise, readable commit logs and I don’t want to lose that.

But let’s say I make a commit like this:

chore(example): write commit message just under the 72 character limit

It’s in another branch. I make a PR for this commit to my main branch. Our CI pipeline (using commitlint-travis) passes. We use the squash merge strategy instead of creating a merge commit so that the history continues to look clean.

Now there’s a commit on our main branch, which appends an issue number. GitHub does this automatically for us.

chore(example): write commit message just under the 72 character limit (#1234)

CI runs again on the new commit on the main branch. This time it fails. The output log looks something like this.

$ commitlint-travis
⧗   input: chore(example): write commit message just under the 72 character limit (#1234)
✖   header must not be longer than 72 characters, current length is 78 [header-max-length]
✖   found 1 problems, 0 warnings
ⓘ   Get help: https://github.com/conventional-changelog/commitlint/#what-is-commitlint

The command "commitlint-travis" exited with 1.

Expected Behavior

A PR that passes commitlint on Travis CI should not fail the build once merged.

Current Behavior

A PR can pass on Travis CI but fail once merged, because the default behavior of GitHub is to append an issue number to the commit, which can potentially increase the header length beyond the limit set by the header-max-length rule.

Possible Solution

Is it possible to do any of the following as potential solutions:

• Override the header-max-length rule with a slightly higher limit depending on where the linter is run (e.g. Travis CI uses a higher limit but locally with husky does not)
• Don’t include issue numbers (syntax matching parenthesis and #number at the end of a header) in the max-length count

One “solution” may be to suggest that developers or code owners manually count the characters in every pull request title and shorten it themselves before merging, but I do not think this is something that can be enforced (if we could do it, we wouldn’t need linters to begin with).

If there’s any other solutions that have already been developed, please let me know.

Context

I will now link to the actual test runs from our real-world application so you can see this occurring in real life:

• The passing PR: https://travis-ci.org/github/streetmix/streetmix/builds/746766308
• The failing merged commit: https://travis-ci.org/github/streetmix/streetmix/builds/746806342

It would be great to be able to have a solution to this, because tests you don’t expect to fail can seem scary. Only after clicking through would one realize what went wrong, and even then it’s not clear why a commit message suddenly failed when it didn’t before, unless you understood exactly what the rule is and what caused it to break.

Thanks!

[iamscottcab]

I just discovered the section on plugins, would it be a good idea for me to explore this as a plugin first?

This was my first thought when I read it the other day. You might be able to make a custom plugin to run on your CI which parses the commit yourself (especially if the format never changes) and do a length test only on the commit message and not the ticket number.

[louh]

Yeah, good question. It seems the references (or ticket numbers) can be anywhere, whereas GitHub’s specific implementation always adds in the same place. Furthermore the rule means that the developer making the commit is responsible for adding it, so they should still be subject to max-length rules.

I think in my mental model because GitHub is making the addition to the commit “automatically” it should just be ignored, as if it doesn’t count at all toward commitlint rules.

I also think that this might need to be an opt-in thing.

I just discovered the section on plugins, would it be a good idea for me to explore this as a plugin first?