Github PR title as input into semantic version instead of commit

[jsbroks]

New plugin motivation

Github does some weird stuff when merging PRs with squash merge (and can be annoying when the pr is a single commit). I would like to use semantic-release but use the PR title instead of the commit message.

Third-party documentation

We'd need to pull done all the merged pull requests in order to get the "commits".

[travi]

semantic-release does not know anything about github PRs at the point when it analyzes commits. while i understand the squash complexities you are referring to, that is out of scope of the details that semantic-release can help you with.

the PR title is only used as a suggestion when squashing and you always have the option to update it. the best i can recommend is to be extra careful about the message before confirming the squash (or use a normal merge instead, so the details of the individual commits are available to semantic-release).

[travi]

Releases are intended to be made from trunk, after a PR is merged. At that point, there is no PR left to evaluate. Instead, it resulted in a commit.

[rantoniuk]

Not really. Releases can be released from hotfix branches and also even with trunk-based development, in our case a PR creates a pre-release build that already should have a proper version determined. This is how feature-based development works.

Imagine:

• 1.0 on trunk
• PR #1 with a title: "feat: new feature" -> that would generate a build 1.1+rc.xx
• PR #2 on hotfix branch, with a title: "fix: some fix" -> that would create a build 1.0.1+build.xx

[travi]

There is still a branch involved, with commits

[rantoniuk]

Sure there is, but you're assuming I want to analyze commit history and I don't. I would like to analyze another input to determine the version, not the commit history, because I can e.g. use it to automatically label PRs and this does not require strict commit message format (and only PR title format).

For example, a developer might push conflicting conventional commit prefixes on a branch (i.e. feat: and fix:) and I want them to consciously name the PR according to whether that is a feat or a fix. This also simplifies creation of GH release notes.

I understand that this is a different approach, but I don't see why an open tool would not be open to extension to parse arbitrary input.

Ref:
https://github.com/marketplace/actions/conventional-commit-in-pull-requests

[travi]

@travi what's your thought on this?

you've asked a maintainer of a volunteer maintained open source project their opinion on whether your desired feature aligns with the goals of the project. in this case it does not. semantic-release works by analyzing commits. if you want to use a workflow that analyzes PR titles, I'm simply highlighting that semantic-release might not be the tool you are looking for. we have to define boundaries around the goals of the project and what is manageable for us to maintain. this request is outside what we've defined as our boundary