feat(parser-emoji): ability to define other emoji #963
Conversation
There was a problem hiding this comment.
I like the idea; might even be good to bake in some common non-triggering types as defaults (even for non-triggering types like docs / ci / chore)?
other_tags seems fine; maybe non_triggering_tags or something similar could also work?
I guess https://github.com/carloscuesta/gitmoji/blob/master/packages/gitmojis/src/gitmojis.json is the closest thing to a standard here?
Just commenting as a user here, but I do personally think having |
Yeah for defaults I (at least think I) added:
Wasn't sure how far to take the defaults. I like gitmoji for reference (and used it for defaults other than what's noted) but I personally deviate a little and think simpler is better, as there can be some overlap/ambiguity when there's too many (and at some point it's annoying to remember them all when they get super specific). I think it'd at least make sense to change
Yeah wasn't sure what to call it. I looked at how the other parsers worked but I preferred how the emoji parser didn't double up with an
Yeah figured it was something along those lines -- just wanted to make sure I wasn't missing any specific risks when I use emoji themselves, as they seem to render everywhere I need them to (whereas the codes don't render in pycharm, for example). Also harder to have a typo when using actual emoji. Easy enough to customize so I don't think it's an issue, was just curious. 👍 |
475dfac to
65657fd
Compare
|
went ahead and swapped |
|
Sorry for the delay, been traveling, hopefully get to the review this week. Initially, I'm not seeing |
Yeah was tough for me to parse the testing structure. I did add/edit these in My understanding is that this does test a commit message's effect on both the type of release and how it appears in changelogs. The first tests to make sure 📝 puts it under the 📝 header because 📝 is defined in the defaults. The second uses 🚧, which is not in the defaults, so it tests to confirm it's under the Sounds like I'm missing something though? |
|
This PR is stale because it has not been confirmed or considered ready for merge by the maintainers but has been open 60 days with no recent activity. It will be closed in 10 days, if no further activity occurs. Please make sure to add the proper testing, docs, and descriptions of changes before your PR can be merged. Thank you for your contributions. |
|
I'm sorry, this was my fault, I was extremely busy the past two months and I didn't get back to reviewing this PR a while back. I will review more over the weekend. I appreciate your contribution to the project. |
|
It has been 60 days since the last update on this confirmed PR. @python-semantic-release/team can you provide an update on the status of this PR? |
I didn't like how using emojis that didn't trigger a release would dump them all together in a generic "Other" category in release notes.
This simply lets you (optionally) define emoji in
other_tagsnon_triggering_tagsso they appear under their own header.Side note: is there a reason the emoji id (like
:construction_worker:) is used instead of the actual emoji (like 👷) in the default configuration? In my personal configurations I just use the actual emojis and it seems to work fine and I like that it renders the emoji in my IDE.