github
github copied to clipboard
No PR comments on prereleases?
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:
-
git checkout feat1
- check out the branch (with a corresponding open GitHub PR) I'd like to prerelease -
git merge master && git mergetool && git commit
- (optionally) merge with master -
git checkout beta && git pull
- fetch the latestbeta
prerelease -
git merge feat1 && git mergetool && git commit
- apply feat1, taking care to keep the currentbeta
version in package.json -
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!
Still very much interested in this!
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.
Thanks for the extensive reply, much appreciated! Am I understanding you correct in that the semantic-release workflow is to
- Branch off
beta
frommaster
- Merge PRs that we wish to include in the
beta
pre-release intobeta
(optionally using the Github PR UI after changing the PR base branch tobeta
) - semantic-release creates pre-releases for every PR merged into
beta
- Once
beta
is ready for a stable release we merge it back intomaster
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?