semantic-release / semantic-release/commit-analyzer
Any notes at all are considered breaking
Nobody has claimed this yet.
- Dominant language
- JavaScript
- Stars
- 448
- Forks
- 82
- Avg merge
- 17h 41m
- Merged PRs (30d)
- 4
Description
We maintain a custom conventional changelog link that we would like to use with semantic-release, but any time we've tried this, any time we merge a PR it's treated as a breaking change because of this line right here:
(!breaking || (commit.notes && commit.notes.length > 0)) &&
It treats any commit note at all as a breaking change. I'm pretty sure this is because the angular conventional discards all notes unless they are a breaking change https://github.com/conventional-changelog/conventional-changelog/blob/master/packages/conventional-changelog-angular/writer-opts.js#L31-L34 (I checked a few other conventional changelogs and did not see them using the notes field at all).
This breaks our conventional changelog because we maintain detailed notes for each of the commits inside of a squashed commit. We use this in other places to analyze the squashed commits to determine what the correct release type is. For example, if a commit looks like this:
fix: Something small
* feat: Add a feat
Then the correct release for that squashed commit would be a feat. Semantic release has this concept itself when multiple commits are released at once, we do the same thing just at a PR level.
That problematic line above means that any PR that is squashed is treated as a breaking change though, which means we end up having to maintain a separate set of release rules which defeats the whole purpose of creating a conventional-changelog for our org.
IMO that line should be changed to scan for BREAKING CHANGE in the notes instead of default treating the presence of a note s a breaking change.
Contributor guide
No contributing guide indexed for this repository
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with lib/analyze-commit.js at the linked condition, then compare how notes are produced in conventional-changelog-angular's writer-opts.js. Reproduce the release analysis for a squashed commit containing ordinary notes and the nested feat example; done means ordinary notes no longer cause a breaking release while genuine breaking notes still do.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- javascript
- Domain
- release
- Issue type
- Bug
- Difficulty
- 3/5
- Estimated time
- 1-2 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 38/100