Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Fix #3300: Use correct GitHub query to find existing Pull Requests
As described in #3300, Scala Steward has been using a now-invalid form of `head` query parameter when querying for existing GitHub Pull Requests. This has meant that it's been trying to raise new pull requests when existing ones with the same branch name were already present, leading to exceptions from the GitHub API. The `head` parameter being used would look like: ``` [organization]/[repo]:[ref-name] ``` ...however the documentation for the `List pull requests` endpoint says it should be just: ``` [organization]:[ref-name] ``` (see https://docs.github.com/en/rest/pulls/pulls?apiVersion=2022-11-28#list-pull-requests) ...it actually _does_ make sense to _not_ have the repo name in there, as it _is_ redundant - the path in the REST API request already contains /repos/{owner}/{repo}/pulls, giving the original repo, and GitHub only allows one fork of a repo per organisation or user, so including the user or org in the prefix should be sufficient to uniquely identify a fork. Although the `[organization]/[repo]:[ref-name]` format must have worked in the past, it looks like GitHub must have made a change that means if you use it to search for PRs by branch name _now_, you'll get zero results - the PRs we're interested in won't come back. Consequently, this change updates Scala Steward to use the approved `head` parameter format, dropping the `/[repo]` part. The code in Scala Steward that constructed the parameter _was_ in the `forge.listingBranch()` method, but once it was fixed to remove `/[repo]`, it became identical to the `forge.createBranch()` method, and so it made sense to go from having 2 methods back to just 1 (there was originally just one `headFor` method back before PR #649).
- Loading branch information