Allow --dry-run option to ignore configured release branches

[walshta]

New feature motivation

For testing if a PR will not cause a release failure, I've configured my GH Actions to run semantic release on any PR targeting a release branch. Since this run is using the --dry-run option it should be safe to run on a PR. This allows for a status check to be required and block any PR that would cause a release failure.

New feature description

Prior to checking if the current branch is a configured release branch or a pull request, check if the --dry-run option was specified. If it was and this is a dry run, allow the process to continue and publish a message stating that this is a dry run and no new version will be published. The expected behavior of a dry run is to run to completion without creating a new version.

New feature implementation

No response

[travi]

you can configure semantic-release to run on any branch already. there should be no need to trigger based on it being a PR since a branch already exists by definition for any PR. trigger based on the branch events instead of the PR events

[walshta]

If I changed the GH workflow to run semantic-release on a push to any branch I would have to allow releases on all branches due to the same issue. --dry-run also refuses to run on a branch that semantic-release doesn't have in is list of allowed release branches. This would allow anyone with write permissions to create a release on any branch without review or approvals simply by editing the GH workflow file to remove the --dry-run.

[travi]

I would have to allow releases on all branches due to the same issue

you can use --branches to override the configured branches list when running the command and set to the current branch.

This would allow anyone with write permissions to create a release on any branch without review or approvals simply by editing the GH workflow file to remove the --dry-run.

i dont understand what this has to do with semantic-release. anyone with write access to your workflow file can modify it to do anything that the workflow is capable of executing. that is not unique to this scenario. if you dont trust who is modifying your workflows, you need to tighten your access controls through codeowners or other means. that is beyong the scope of responsibility of semantic-release