The GitHub API search endpoint could be called only once

[pvdlg]

Hello!

I'm working on a similar feature for semantic-release. It would also add to the issue comments things that are only available in the context of semantic-release such as the links to the different release locations (e.g. GitHub release, Atom package, npm package + dist-tag info etc..).

I was looking at the code of this app to get started and while experimenting with the GitHub API I figured the search endpoint can be called once for multiple commits.

It seems that currently it's called for each commit in the release:

release-notifier/index.js

Line 60 in 9ae8ead

const {data: {items: [pullRequest]}} = await context.github.search.issues({q: commit.sha})

A list of commit sha can be passed separated by +. In addition passing the criteria repo:<owner>/<repo> would limit the search to the current repo (might help on GitHub side by limiting the scope) and type:pr allows to guarantee only PRs are returned (I found some cases where a random issue was returned in addition of the expected PR).

Doing so would limit the number of calls to the GitHub API, especially for releases that include a lot of commits.

You can see an example here.

On a side note, I created the module issue-parser that parses PRs, issues and commit body to find issues closed via keywords. It's used here and allow to also add a comment to issues closed from the PRs and commit via keywords. In case you are interested.

[pvdlg]

As it turns out the search issue endpoint accept a string of maximum 256 characters in the q parameters.
So it's not always possible to make only one search depending on the number of commits.

See semantic-release/github#36 for a function that build the minimum number of search queries possible.

Doing so would still reduce the number of queries made by up to a factor of 6 (as one query fits 6 commits sha).

To optimize further it's also possible to truncate commit sha to 7 characters.

[zeke]

Wow this is awesome, @pvdlg. Thanks for reporting it here.

Is semantic-release/github#36 the best spot to watch for developments on the modularization of this approach?

[pvdlg]

Not sure it worth modularizing that as it's specific to the GitHub API. Per @gr2m comment in semantic-release/github#36, that should be moved to @octokit/rest, so that would be the best place to look for that.

[gr2m]

I'll keep y'all posted on the @octokit/rest front :)