Automated way to follow conventional commits when merging PRs with a single commit

[ghost]

Currently we check that pull request titles follow conventional commits using semantic pull requests. This allows us to ensure that PRs with multiple commits merged using "squash and merge" function in GitHub UI have semantic commit messages.

However, when a PR has just a single commit, the commit message automatically generated by GitHub uses not PR title, but the message from the commit itself. Thus, semantic pull request check does not ensure that the merged commit follows conventional commits. This issue is discussed in zeke/semantic-pull-requests#17.

I'm not sure what it is the best way to have this automated, but I have a proposal. The idea is to disable "squash and merge" in GitHub and instead set up a bot which would merge PRs on behalf of maintainers when asked to do so by one of maintainers in a PR comment. For example, Rust core team does this with bors merging PRs automatically when they are approved by one of maintainers. It might make sense for us to set up something similar.

Related to #1102.

[lukesteensen]

Yeah, I've thought about looking into a bors-like infrastructure for us. It would also help avoid cases where there are weird merge artifacts after "conflicting" PRs like in #1087.

[LucioFranco]

I was always under the assumption the commit that was merged uses the PR title. Was this changed?

[ghost]

I was always under the assumption the commit that was merged uses the PR title. Was this changed?

I'm not sure was it always like this or not, but ccae97b is an example of merging a single-commit PR without changing the default title.

[LucioFranco]

What confuses me is last night I merged a PR on one of my projects and I changed the commit name.

commit on master
hyperium/tonic@c9b7523

and PR hyperium/tonic#109

You can see that the commit by the user was different? I bring this up because personally I really like this workflow. Bors is good but I dislike merge commits and I don't like to impose commit rules on users. I like squash because as a maintainer you can fix their commits easily. Now if this has changed it won't work but that was my motiviation around using squash and merge.

[ghost]

@LucioFranco Are you using a browser extension like "Refined GitHub"? It is mentioned in zeke/semantic-pull-requests#17 as changing this behavior.

[LucioFranco]

@a-rodin ah yes I am, so if I understand correctly then refined github is auto populating the field for me, but this still means the final title and message when you click squash does become the commit? So its on the person merging to ensure it follows? That still seems fine to me to enforce, we should all be aware of the convention.

[ghost]

So its on the person merging to ensure it follows? That still seems fine to me to enforce, we should all be aware of the convention.

Yeah, so basically I was thinking about ways to exclude possibility of a human omission here without additional extension (to make it possible to easily merge from a phone/tablet, for example). But it might not be the highest priority for now.

[binarylogic]

Closing since we cannot fix this. Refined Github fixes this and we encourage users to use this if possible.