Allow branches not under --heads (/ref/heads) to be used as release branches

[pksorensen]

New feature motivation

On azure devops, each pr is located in ref/pull* and we would like to use those as prerelease branches.

I discovered that it wont work due to the filter of --heads here:

export async function getBranches(repositoryUrl, execaOptions) {
  return (await execa("git", ["ls-remote", "--heads", repositoryUrl], execaOptions)).stdout
    .split("\n")
    .filter(Boolean)
    .map((branch) => branch.match(/^.+refs\/heads\/(?<branch>.+)$/)[1]);
}

New feature description

Would it be possible to extend semantic release in a way to opt in by a cli argument to allow any remote branch not only from ref/head * `?

New feature implementation

No response

[pksorensen]

@travi - what do you think, is that acceptable to contribute into to semantic-release? If not, is there any other path to achieve the same thing using extensions/plugins somehow?

[seebeen]

Before Travi comes in - may I ask what is the reasoning behind the feature?

[travi]

each pr is located in ref/pull* and we would like to use those as prerelease branches

first of all, (pre-)releasing every PR in order to test whether it works or not is not an officially supported use of the pre-release workflow. pre-releases are intended for collaborating with consumers before a release that includes changes that need design agreement and similar situations, not as part of a testing process. a testing process should be able to isolate the behaviors of a library without needing to publish a version for each potential change. details of how a project decides to accomplish that goal is beyond the scope of what semantic-release intends to cover.

given that, we are aware that some of our users have decided to use pre-releases to accomplish something similar to such a testing workflow. you can likely find some examples in historical issue discussions. since this is not an officially supported use of the pre-release workflow, we have to draw a line from a support perspective and say you are on your own perusing such a goal and we make no guarantees that the approach wont be broken by future changes to the project. therefore, we are also not interested in adding additional complexity to the project for an unsupported workflow.