Possible optimizations for `commitMode: github-api`

[h3rmanj]

When doing my testing in #472, I noticed some possible oppertunities for optimization for the commitMode: github-api.

Creating tags/releases

#472 (comment)

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

#472 (comment)

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

[h3rmanj]

I'm not seeing any calls in this action to explicitly close a pull request. Does all that happen in @changesets/ghcommit?

[s0]

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.

I'm not seeing any calls in this action to explicitly close a pull request. Does all that happen in @changesets/ghcommit?

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:

• create a new branch using an existing commit: createRef
• update an existing branch to a different existing commit updateRef
• add a new commit to an existing branch: createCommitOnBranch

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:

1. update the existing branch to match the base branch first (which will then cause GitHub to automatically close the PR, as there's no diff).
2. add the new files using createCommitOnBranch
3. re-open the existing PR

If 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]

@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.

[bluwy]

Second point is addressed in changesets/ghcommit#70