Repository navigation
Possible optimizations for commitMode: github-api #474
Description
When doing my testing in #472, I noticed some possible oppertunities for optimization for the commitMode: github-api.
Creating tags/releases
I think we could reduce the API requests when creating releases/tags in half, if you provide target_commitish to the createRelease call, and drop the createRef call that creates the tag.
We would need to check that it still achieves the desired results in regards to signing tags.
Creating pull requests
When commitMode: github creates a pull request, it does the following:
- It first pushes the base branch to the changeset branch <- This could be removed
- Then commits the result from version
- Then opens a pull request
And on subsequent changes, it also closes the pull request before opening a new one (in addition to the double push), which I suspect could be removed as well.
cc @s0
Metadata
Metadata
Assignees
Labels
No labels
Activity
h3rmanj commentedon May 9, 2025
I'm not seeing any calls in this action to explicitly close a pull request. Does all that happen in
@changesets/ghcommit?s0 commentedon May 9, 2025
So with the GitHub API, there's no way to perform a force-push in a single operation with new content (i.e. file changes), you can only, in separate API calls:
See our implementation here: https://github.com/changesets/ghcommit/blob/main/src/core.ts#L48
What this means is for existing PRs, we have to:
createCommitOnBranchIf GitHub update the [createCommitOnBranch] mutation to allow us to specify a different parent commit / oid, then this would avoid the situation where PRs automatically close, and we could remove 2 API calls for existing branches. But until this happens I doubt there is much we can do.
h3rmanj commentedon May 12, 2025
@s0 Thanks for taking a look! Sounds like there isn't anything we could do differently for commiting then.
I created a PR for the creation of tags/releases, but the impact of that is probably smaller.
revert(ci): merge version and release back into a single workflow
bluwy commentedon Jun 14, 2026
Second point is addressed in changesets/ghcommit#70