Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Allow skipping MR/issue comments based on commit types #480

Closed
nejch opened this issue Jan 11, 2023 · 8 comments
Closed

Allow skipping MR/issue comments based on commit types #480

nejch opened this issue Jan 11, 2023 · 8 comments
Labels

Comments

@nejch
Copy link

nejch commented Jan 11, 2023

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
Copy link
Contributor

I like the idea! @travi @gr2m WDYT?

@travi
Copy link
Member

travi commented Jan 13, 2023

we have had requests for similar with the github plugin, such as semantic-release/github#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 semantic-release/semantic-release#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
Copy link
Author

nejch commented Jan 28, 2023

@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
Copy link

olexs commented Feb 27, 2023

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
Copy link
Contributor

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 semantic-release/github#359 as the Issue/PR/MR objects are also available in the template.

@babblebey
Copy link
Member

Hi @fgreinacher,

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

@fgreinacher
Copy link
Contributor

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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants