Feature request: exclude PRs with specific labels from commenting

[ylemkimon]

This is somewhat similar to #359.

There may be some PRs that don't need release comments, such as dependency management and chores. It'd be nice to exclude them by labels like:

--- a/lib/success.js
+++ b/lib/success.js
@@ -28,6 +28,7 @@ module.exports = async (pluginConfig, context) => {
     successComment,
     failComment,
     failTitle,
+    excludeCommentLabels,
     releasedLabels,
     addReleases,
   } = resolveConfig(pluginConfig, context);
@@ -45,7 +46,8 @@ module.exports = async (pluginConfig, context) => {
     const releaseInfos = releases.filter((release) => Boolean(release.name));
     const shas = commits.map(({hash}) => hash);
 
-    const searchQueries = getSearchQueries(`repo:${owner}/${repo}+type:pr+is:merged`, shas).map(
+    const labelQuery = excludeCommentLabels ? excludeCommentLabels.map((label) => `+-label:"${label}"`).join('') : '';
+    const searchQueries = getSearchQueries(`repo:${owner}/${repo}+type:pr+is:merged${labelQuery}`, shas).map(
       async (q) => (await github.search.issuesAndPullRequests({q})).data.items
     );

[melink14]

I don't even think labels are needed; it was very surprising that this was posted for commits which were not part of the release spec.

Given that the plugin is given information on which commits are considered 'worth making a release' for, maybe there should be an option for 'only include version changing commits'?

<I can start a new issue for this but added it here because the reasoning for wanting it is the same; exclude chore/docs and other PRs which may not go to users>

[melink14]

I looked through the plugin development guide and it seems a filtered list of commits isn't passed through context so a preset based fix isn't as trivial as I thought.

It seems like the expectation is all filtering steps (analyze, generate notes) are expected to just use the same filtering logic independently.

github could do that too but it may be too ancillary compared to its core function so maybe a label based mechanism would be more palatable to the maintainers?