Release not created, when expected to have a release created

[vincentbriglia]

Describe the bug

using conventional commits, with a few fixes, features and chores - a release doesn't get created.

To Reproduce

https://github.com/LEGO/klik/runs/2169371508

Expected behavior

Creating releases is sometimes unpredictable.

Screenshots

Environment information:

Additional context

[hipstersmoothie]

Looks like this happened because of the conventional commits plugin counting chore: as a skip release. I've opened this pr to enable configuration of this behavior

[vincentbriglia]

so if there are say 10 commits in my PR, 9 are "fix" and 1 is "chore" ... it finds a chore and then skips ?
with the behavior in the PR, that means that 10 chores would essentially create a release ?

would it make more sense to change our workflow and "squash" our commits?

[vincentbriglia]

I created an extra PR and merged it into main https://github.com/LEGO/klik/runs/2170303293 and then it caught all commits, so there is something not "correct".

is it perhaps just the last commit that is taken into consideration? 9 "fix" commits, last commit is a "chore" and then it just doesn't release ? could that be

I'm fine with the behavior of "chores" not creating releases, but if a PR contains 10 commits, and in that list of commits is a single fix, i would expect something to be released. the question is, would that be the whole PR? or just the commits all the way up to the latest "fix" or "feat".

maybe i'm not understanding the default workflow using conventional commits, would like to hear your thoughts

[hipstersmoothie]

I think what you want is this #1723 with a little more logic around a set of conventional commits. I'll do some testing on your repo and see what I find

[vincentbriglia]

I think the behavior I'm after is "do commits since last release for a package contain any fix or feat, make a release accordingly. if only chores, ignore" ... if this it too much of a breaking change, i can understand that perhaps we should change our workflow to squash/commit

[vincentbriglia]

I think what you want is this #1723 with a little more logic around a set of conventional commits. I'll do some testing on your repo and see what I find

I think you're right, let me know how i can help

[hipstersmoothie]

Finally taking a look at this. Sorry for the delay

[hipstersmoothie]

Just want to be clear:

1. You aren't asking for each conventional commit to be in the changelog
2. You are asking for a change to the conventional-commits plugin that takes into account all the conventional commits in a PR to determine the releaseType for that PR

#1723 fixes 2 but not 1

[adierkens]

🚀 Issue was released in v10.23.0 🚀