Allow skipping MR/issue comments based on commit types

[nejch]

Not sure if this would be consistent with the GitHub plugin, but it would be cool to be able to filter getRelatedMergeRequests based on commit messages in those MRs.

For example, only comment on them and their related issues if their commits contain a release-relevant commit type (feat/fix/breaking change etc), to reduce noise once a release is done, especially for chore MRs that bump dependencies and similar.

Something like "commentOnCommitType": ["feat", "fix", "breaking"] or so :)

[fgreinacher]

I like the idea! @travi @gr2m WDYT?

[travi]

we have had requests for similar with the github plugin, such as https://github.com/semantic-release/github/issues/359. it would be ideal to be consistent with github and gitlab if we were to add this functionality.

since we are in the middle of the esm transition and starting to build a bit more momentum, i would like to get past https://github.com/semantic-release/semantic-release/issues/2133 before giving serious consideration to bringing it into the github plugin. for me to give it full consideration, i think after that happens would be the best time bring it back up for focused consideration again.

[nejch]

@travi sure, no rush. Thanks for considering this!

The GitHub plugin issue seems slightly different in that it's more about duplicate comments in non-linear/multi-branch release workflows whereas this would be more about filtering based on type from the get-go. But I understand you'd want to have some kind of consistent approach to adding conditions for creating comments.

[olexs]

We have a similar use case in a project, I've been looking at related issues and this is probably the closest short of opening a completely new discussions.

What we would like is to be able to enable or disable successComment based on the branch configuration, specifically we'd like to disable the function for pre-releases and keep it enabled for "proper" releases.

The Lodash template function used for successComment already can access a lot of necessary metadata, as described here: https://github.com/semantic-release/gitlab#successComment (including the branch, and targeted MR/issue, which would help the OP use case). If there was a way return a value from the template function that basically says "skip posting the comment", this would solve both our cases. This would need to be implemented around https://github.com/semantic-release/gitlab/blob/master/lib/success.js#L32 and https://github.com/semantic-release/gitlab/blob/master/lib/success.js#L48.

[fgreinacher]

Sorry for getting back to this that late.

The Lodash template function used for successComment already can access a lot of necessary metadata, as described here: https://github.com/semantic-release/gitlab#successComment (including the branch, and targeted MR/issue, which would help the OP use case). If there was a way return a value from the template function that basically says "skip posting the comment", this would solve both our cases.

This sounds like a good idea to explore deeper. Probably we could skip posting the comments if the template returns an empty string. This could also be a solution for https://github.com/semantic-release/github/issues/359 as the Issue/PR/MR objects are also available in the template.

[babblebey]

Hi @fgreinacher,

Following the merge of PR #730, can this Issue and #636 be closed as completed!? 🤔

[fgreinacher]

Hi @fgreinacher,

Following the merge of PR #730, can this Issue and #636 be closed as completed!? 🤔

Yes @babblebey, all of them should be solved now 🎉

[fgreinacher]

@olexs @nejch The new option successCommentCondition should do the job 😀