`semantic-release` comments on already included PRs

[kallioaleksi]

We made our first release with semantic-release last week, and now we're pushing the next beta branch (1.1.0-beta.1). It seems that with the default configuration semantic-release comments on some PRs which were already included in the 1.0.0 release.

Is there a setting to comment only on the new PRs for each release, or at least PRs merged since the last production release?

[travi]

what you are describing sounds like you are likely using gitflow. it is worth being aware that the pre-release workflow enabled by semantic-release is not intended to be a testing workflow and gitflow is officially unsupported.

the most likely situation to result in this is that your beta branch does not contain the released 1.0.0 in its history. the intended use of the pre-release workflow is to delete the beta branch after the pre-release is complete and has been promoted to stable. then the next (hopefully rare, not for every potential release) beta that the project needs should be branched from the latest commit of the default release branch. this expectation is part of what makes the pre-release workflow not an idea match for gitflow. at minimum, you need to merge the default release branch into the beta branch if it is a branch that outlives the original pre-release

[kallioaleksi]

Thanks for clarifying. In our case, we use something resembling gitflow before main, but use environment branches and semantic-release after main. Beta releases are done by merging to env/dev, which after running semantic-release (beta workflow) deploys in dev environment. After validating the release in dev env, main is pushed to env/staging (which deploys to staging) and finally to env/prod, which runs the actual release configuration and deploys to prod.

I think the part that confuses semantic-release is that dev/env is not pushed to other branches, the pushes are done from main. We'll try changing this, and it should help since the beta releases will be in history, but still the actual releases won't be, unless we merge the env/prod branch back to main.

[travi]

it is safe to say that we do not have a supported workflow that supports the workflow you describe. if you believe it is worth leveraging semantic-release for your goal, you are welcome to try, but be aware that your approach is unsupported. semantic-release targets a workflow that aligns closer to github flow or continuous delivery.

it sounds like you are releasing an application rather than a library with what you describe. can you share what value is provided by versioning the app with semver? that is an approach that i normally purposely avoid with applications