Possible to ignore PR's title for analysis? about commit-analyzer HOT 8 CLOSED

semantic-release does not look at the PR title or message. It looks only at the commit messages.
So as long as you preserve all your commits that will work (e.g. keep all the commits and don't squash them)

from commit-analyzer.

The PR's title becomes the commit message after merge. And you lose the commits after merging to base branch.

So,

• PR Branch develop - preserves commits but release doesn't happen here
• develop branch master - sees only the commit to develop, as opposed to the original PR's commits. And unless the PR's title conformed to conventional-changelog rules, commit analyzer will mark this change as "nothing to publish".

from commit-analyzer.

I don't know what Git platform you are using, but neither on GitHub, GitLab nor Bitbucket the PR title becomes the commit message. PR title and commit messages are independent.

semantic-release runs on the branch you configure, parse the commit there and make the release. No way around this is the core concept of semantic-release. If you use a process where your commits are lost on the way to master then there nothing we can do.

We strongly recommend to have all the commit on the master branch as it gives you a clear history of your codebase changes.

from commit-analyzer.

Happens on github. You can see this here

And one of the corresoponding PR: dowjones/react-dropdown-tree-select#116

We strongly recommend to have all the commit on the master branch as it gives you a clear history of your codebase changes.

A lot of folks use gitflow and even if you don't use gitflow, develop/master is a convention that lot of teams/devs follow. Another issue with master is, that it generates one liner releases. I'd like to have some control on the release process and basically be able to combine these mini releases into one (should I chose to). Here's an example:

And this is just an example. Even if it might be a good idea to have such frequent releases for public libs, it becomes noisy in an internal environment. Think about an enterprise app that gets released every 2 weeks or 4 weeks and contains bunch of updates (fixes, enhancements etc). The usual practice is to pile up these small changes in develop branch and once it's time to release, cut a PR for master.

from commit-analyzer.

I guess that happens because you merged that PR with "Squash and Merge". As mentioned above if you squash your commit you will end with one commit per PR and loose the history of commit.

from commit-analyzer.

Right, why would I pollute commit history on master with branch commit history? I can always get to them if needed (and github makes it dead simple).

But is there anyway to tweak this process (if not commit analyzer then maybe somewhere else in semantic-release universe)?

How are other libs, even Angular able to generate those detailed changelogs that are not one liners? Are they doing parts of the process manually or is there something I'm missing?

from commit-analyzer.

As explained before semantic-release parse the commit on the branch you configure. If you have commits following the convention, they will be analyzed and use to determine the next release.
It doesn't matter if you add the commits one by one (and run semantic-release in between) or if you add multiple at the same time. semantic-release will generate a changelog including all the commits since the last. If you added one it's gonna one, if you added 10 it's gonna be 10.

If you want to "park" your commits on a branch before merging them to master so you can release multiple at a time, that's fine. But as explained before if you squash them, then semantic-release has no way to know that the squashed commit comes from 10 commits formatted with the convention.

It seems what you call "pollution" is the actual change history of your codebase formatted following the convention. The very thing that semantic-release analyze on your release branch.

If you don't want to have your commit history formatted with the convention in your release branch and just commits like "release xxx", "release yyy" or "whatever your squashed commit message is" then you can't use semantic-release.

from commit-analyzer.

I see. Thanks for the clarification.

A PR often has several commits that are not necessarily info that I'd like to preserve. Sometimes it's just chatter, which makes sense when isolated and limited to a PR's context but when merged to main branch, just becomes noise.

Thanks again for your patience! semantic-release is a great tool and like every other tool, it has its uses and limitations!

from commit-analyzer.