Problem
The branch input currently serves two conflicting purposes in src/run.ts:
-
Version branch name suffix (line 281):
let versionBranch = `changeset-release/${branch}`;
-
PR base/target branch (line 375):
const { data: newPullRequest } = await octokit.rest.pulls.create({
base: branch,
head: versionBranch,
...
});
This coupling makes it impossible to have separate release staging branches per workspace while all targeting the same base branch (e.g., main).
Use Case
In a multi-workspace monorepo (e.g., many pnpm workspaces in one repo), each workspace needs to release independently via separate changesets-action invocations. You'd want:
- Workspace A → version branch
changeset-release/workspace-a, PR targets main
- Workspace B → version branch
changeset-release/workspace-b, PR targets main
But this is impossible today because:
- If you set
branch: main for all workspaces, they all collide on changeset-release/main
- If you set a unique
branch per workspace (e.g., branch: changesets-workspace-a), the PR base becomes changesets-workspace-a which doesn't exist, resulting in:
creating pull request
Error: HttpError: Validation Failed: {"resource":"PullRequest","field":"base","code":"invalid"}
Suggested Fix
Split the branch input into two separate inputs:
Option A — Add a new headBranch / versionBranch input:
- uses: changesets/action@v1
with:
branch: main # PR base (existing behavior)
versionBranch: changeset-release/workspace-a # override the version branch name
Option B — Split into baseBranch + branchSuffix:
- uses: changesets/action@v1
with:
baseBranch: main # PR target
branchSuffix: workspace-a # → changeset-release/workspace-a
Either approach is backwards-compatible — the existing branch input would continue to work as before when the new input is not provided.
Related Issues
All of these are symptoms of the same underlying design issue: branch is overloaded to mean both the version branch suffix and the PR base.
Problem
The
branchinput currently serves two conflicting purposes insrc/run.ts:Version branch name suffix (line 281):
PR base/target branch (line 375):
This coupling makes it impossible to have separate release staging branches per workspace while all targeting the same base branch (e.g.,
main).Use Case
In a multi-workspace monorepo (e.g., many pnpm workspaces in one repo), each workspace needs to release independently via separate changesets-action invocations. You'd want:
changeset-release/workspace-a, PR targetsmainchangeset-release/workspace-b, PR targetsmainBut this is impossible today because:
branch: mainfor all workspaces, they all collide onchangeset-release/mainbranchper workspace (e.g.,branch: changesets-workspace-a), the PR base becomeschangesets-workspace-awhich doesn't exist, resulting in:Suggested Fix
Split the
branchinput into two separate inputs:Option A — Add a new
headBranch/versionBranchinput:Option B — Split into
baseBranch+branchSuffix:Either approach is backwards-compatible — the existing
branchinput would continue to work as before when the new input is not provided.Related Issues
"field":"base","code":"invalid"error (most directly related)branchinrunVersion#254 — Original request forbranchinput customizationAll of these are symptoms of the same underlying design issue:
branchis overloaded to mean both the version branch suffix and the PR base.