No PR comments on prereleases?

[mogelbrod]

I've got a private NPM (GitHub package repository to be exact) package released via semantic-release with a beta prerelease channel: release.config.js

Whenever I wish to trigger a beta release (by following these instructions) I do the following:

1. git checkout feat1 - check out the branch (with a corresponding open GitHub PR) I'd like to prerelease
2. git merge master && git mergetool && git commit - (optionally) merge with master
3. git checkout beta && git pull - fetch the latest beta prerelease
4. git merge feat1 && git mergetool && git commit - apply feat1, taking care to keep the currentbeta version in package.json
5. git push origin - trigger release

The release finishes successfully and publishes the correct beta version to the registry. However it never seems to post a comment to the open feat1 PR, instead opting to post comments to merged PRs that have already been released on the master branch (and therefore already have a "released in version X" comment) - similar to this PR.

Is this caused by bad configuration, or is there anything else I can do to not have to resort to manually writing "released in X" comments on the PR?

By the looks of https://github.com/semantic-release/github/issues/105#issuecomment-418170667 it sounds like I need to reference the PR number in the merge commit, is that correct?

Thanks in advance!

[mogelbrod]

Still very much interested in this!

[travi]

i dont think i understand the desired workflow. comments are added to closed PRs and issues so that followers of those threads can be notified that the related changes have been released. therefore, the comments do not apply to open PRs like you seem to be asking for.

in addition, it is expected that the pre-release branch would normally be created from your mainline branch (sounds like this would be master in your example). if following that approach, i would not expect step 2 to be necessary. if you are creating the pre-release branch from some other branch and then merging your mainline into it, this would result in the behavior you describe where comments are added to threads that have already been released on the mainline. that is because semantic-release relies heavily on history as defined by git and the merge results in those commits happening after you initiated the pre-release channel. please keep in mind that semantic-release does not officially support gitflow, which it sounds like might be the process you are trying to use. instead, we strongly encourage using github flow or trunk-based development when working on packages.

[mogelbrod]

Thanks for the extensive reply, much appreciated! Am I understanding you correct in that the semantic-release workflow is to

1. Branch off beta from master
2. Merge PRs that we wish to include in the beta pre-release into beta (optionally using the Github PR UI after changing the PR base branch to beta)
3. semantic-release creates pre-releases for every PR merged into beta
4. Once beta is ready for a stable release we merge it back into master

Should the beta branch be re-created from master the next time it's time for a beta pre-release, or is it typically kept around and new PRs simply merged into it on demand?