Thanks for the PR @Hakihiro, greatly appreciated!

As mentioned in #480 (comment) I would prefer to solve this without a new configuration option.

Otherwise we might end with many similar options like commentSuccessForBranches, commentSuccessForStableVersions and in the worst case we'd need combinations of them 😬

Thanks for the PR @Hakihiro, greatly appreciated!

As mentioned in #480 (comment) I would prefer to solve this without a new configuration option.

Otherwise we might end with many similar options like commentSuccessForBranches, commentSuccessForStableVersions and in the worst case we'd need combinations of them 😬

Hi @Hakihiro and thanks a lot for your contribution. I agree with @fgreinacher the risk of configuration overhead is too big and trying a templating attempt might be more sustainable.

I understand your point of view. I'm not a big fan to put an information inside a template message to determine on which target(s) it should be posted. But I understand your fear about the unsustainable configuration becoming quickly unmainteable.

I will try to extract this information from the successMessage with lodash template, base on the following syntax:
[to issues] - [to merge-request] - [to issues,merge-request]

Is this something more suitable for you?

Thanks for your feedback

Thanks a ton!

I will try to extract this information from the successMessage with lodash template, base on the following syntax:
[to issues] - [to merge-request] - [to issues,merge-request]

That's not even needed. The idea would be to not create the note if the rendered template returns a falsey value:

https://github.com/semantic-release/gitlab/blob/master/lib/success.js#L31-L38

Users could then define a template like this to indicate that they only want comments on issues (not sure about the exact syntax, needs some experimentation with the lodash template engine:

<% if (issue) { %> regular comment <% } %>