fix: successComment value in @semantic-release/github config #212
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
All Submissions:
Changes proposed in this Pull Request:
Fixes blocking errors in the
release
script (example):In the current release,
successComment
evals totrue
if the base branch is arelease
,alpha
, orhotfix
branch.true
isn't a valid value for this option in the@semantic-release/github
plugin—if we want the default commenting behavior, we should simply omit the option from the config object.This patch only assigns
successComment
a value offalse
(meaning we don't want@semantic-release
to post a comment to the PR) if the base branch isn't arelease
,alpha
, orhotfix
branch. If the base branch IS one of these, omittingsuccessComment
from the config should result in@semantic-release
posting a default success message to the PR.How to test the changes in this Pull Request:
Can't think of a way to test this without letting it fly..
Other information: