おそらくはそれさえも平凡な日々

GitHubのissue searchには複数のSHAを指定できる

GitHubのissue search APIは、コミットハッシュ(SHA)を指定でき、そのコミットが含まれるpull requestを検索できます。7文字以上のHEX文字列を渡せば、それをSHAとみなしてくれる仕様です。

ref. https://docs.github.com/en/search-github/searching-on-github/searching-issues-and-pull-requests#search-by-commit-sha

このとき、複数のSHAを検索文字列に渡すとOR検索の扱いになり、いずれかのコミットが含まれるpull requestをまとめて抽出してくれます。

これは、まだ明確にドキュメントされていませんが、GitHubのサポートに問い合わせたところ、「妥当な挙動である」と回答をもらいました。なので追加で、ドキュメントして欲しい旨も伝え、ドキュメントチームにフィードバックする、との回答ももらっています。

余談ですが、GitHubのサポートは、大昔に比べるとかなり体験が向上していました。https://support.github.comからサポートを起票でき、それが使い慣れたGitHubと似た操作で行えるのが良かったです。また、レスポンスも非常に早くてありがたかった。

これで何が個人的に嬉しいか

squashed mergeされたpull requestをまとめて検索したいときに嬉しい。つまり、git-pr-release で嬉しい。

最新のgit-pr-release (2.0.0)には、squashed mergeを検出する --squashed オプションが入っていますが、これは、コミットハッシュとGitHub Search APIを使って、pull requestを抽出する作りになっています。

ただし、現状は、一つのSHA毎にAPIリクエストを投げるため、すぐリクエスト制限に引っかかってしまう。Search APIはRate Limitが厳しく、1分間に30回もしくは10回に設定されています。(どうもGitHub Actions上のsecrets.GITHUB_TOKEN は権限が弱く、10回になっている気がする)

ref. https://docs.github.com/en/rest/reference/search

なので、このSearch APIの挙動を利用して、リクエストをまとめる修正を作って、git-pr-releaseにpull requestを送った。その前段として、merge commitからpull requestを取得できる場合には、search APIを使わないようにする修正も作った。

これらが入ると、squashed mergeも素早く検出でき、今の私の社内の実用に耐えるものになる。実際、現在社内で、specific_install して試しているが快調に動いている。また、将来的にはこれをデフォルト挙動にしても良いかも知れない。なぜならば、GIT_PR_RELEASE_BRANCH_STAGING にマージコミットしかない場合は、search APIへのリクエストは飛ばないからである。

OSSへの機能追加要望について

とは言えgit-pr-release内でsquash mergeをどれくらいケアするかというのは開発者のポリシーに関わる問題です。開発者のユースケースとしてsquash mergeを使わないのであれば、ある意味「余計な」機能を入れてしまうことに他ならない。実際、私もこれまでの職場の社内プロジェクトではsquash mergeを使わないプロジェクトしかなく、そのようにワークフローを統一してしまえば大きな問題はないため、実際squashをケアする必要性を感じていませんでした。

ただ、今回は、現職でsquash mergeが使われるケースがあるのと、--squashed オプションがいつの間にか生えていることに気がついたので、それに乗っかって改善させてもらうことにしたというところです。

このあたりのOSSのオーガナイズは難しいよなぁ、というのを自分でpull requestを送りながら勝手に思いを馳せていました。

created at
last modified at
comments powered by Disqus