Scala Steward attempting to raise PRs for group branches that already have PRs

[rtyley]

I'm not certain that this is Scala Steward's fault, but some pretty weird has definitely been happening to our Scala Steward runs since 10am London time today:

We're running Scala Steward using scala-steward-action, over about 57 repos - and for most of them (maybe 47 repos), Scala Steward is attempting to raise a new PR for a group of updates where the branch already exists.

Our scala-steward.conf defines two pullRequests.grouping, (aws and non_aws), and for both of them, the branches used by Scala Steward (update/aws & update/non_aws) are often already existing as PRs in the repos - but that isn't stopping Scala Steward from trying to raise new PRs on those branches - which GitHub rejects:

body: {"message":"Validation Failed","errors":[{"resource":"PullRequest","code":"custom","message":"A pull request already exists for guardian:update/non_aws."}],"documentation_url":"https://docs.github.com/rest/pulls/pulls#create-a-pull-request"}

This is happening quite consistently. I would guess that somehow in the code below, the check for the existing PR on line 101 is somehow getting bypassed, leading to a new PR being created:

scala-steward/modules/core/src/main/scala/org/scalasteward/core/nurture/NurtureAlg.scala

Lines 94 to 104 in 1fe2aab

	_ <- logger.info(s"Process update ${data.update.show}")
	head = forge.listingBranch(config.tpe, data.fork, data.updateBranch)
	pullRequests <- forgeApiAlg.listPullRequests(data.repo, head, data.baseBranch)
	result <- pullRequests.headOption match {
	case Some(pr) if pr.state.isClosed && data.update.isInstanceOf[Update.Single] =>
	logger.info(s"PR ${pr.html_url} is closed") >>
	deleteRemoteBranch(data.repo, data.updateBranch).as(Ignored)
	case Some(pr) if !pr.state.isClosed =>
	logger.info(s"Found PR ${pr.html_url}") >> updatePullRequest(data, pr.number)
	case _ =>
	applyNewUpdate(data).flatTap {

[rtyley]

This appears to because the head string used by listPullRequests() (which is supposed to be finding us the existing PRs) is not being accepted by the GitHub API.

We're sending head=guardian/facia-scala-client%3Aupdate/aws, which is returning 0 results. On the other hand, if I manually make the request to the GitHub API, with head=update/aws, I get results:

scala-steward/modules/core/src/main/scala/org/scalasteward/core/forge/github/Url.scala

Lines 31 to 33 in c317b87

	def listPullRequests(repo: Repo, head: String, base: Branch): Uri =
	pulls(repo)
	.withQueryParam("head", head)

% curl --silent "https://api.github.com/repos/guardian/facia-scala-client/pulls?head=guardian/facia-scala-client%3Aupdate/aws&base=main&state=all" | head
[

]
% curl --silent "https://api.github.com/repos/guardian/facia-scala-client/pulls?head=update/aws&base=main&state=all" | head
[
  {
    "url": "https://api.github.com/repos/guardian/facia-scala-client/pulls/307",
    "id": 1747950527,
    "node_id": "PR_kwDOATw1z85oL5u_",
    "html_url": "https://github.com/guardian/facia-scala-client/pull/307",
    "diff_url": "https://github.com/guardian/facia-scala-client/pull/307.diff",
    "patch_url": "https://github.com/guardian/facia-scala-client/pull/307.patch",
    "issue_url": "https://api.github.com/repos/guardian/facia-scala-client/issues/307",
    "number": 307,

The documentation for the API endpoint says:

head string
Filter pulls by head user or head organization and branch name in the format of user:ref-name or organization:ref-name. For example: github:new-script-format or octocat:test-branch.

There's nothing in there that to suggest that we can include the repo name as well (ie. guardian/facia-scala-client%3A)...

[rtyley]

The head name is constructed in listingBranch(), which is code that does not appear to have changed much recently...

scala-steward/modules/core/src/main/scala/org/scalasteward/core/forge/package.scala

Lines 28 to 35 in 1005ebe

	def listingBranch(forgeType: ForgeType, fork: Repo, updateBranch: Branch): String =
	forgeType match {
	case GitHub =>
	s"${fork.owner}/${fork.repo}:${updateBranch.name}"
	case GitLab | Bitbucket | BitbucketServer | AzureRepos | Gitea =>
	updateBranch.name
	}

The repo name does seem redundant, as 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/org in the prefix should be sufficient to uniquely identify a fork.

It does look as though, in the past with #649 in 2019, the Scala Steward code deliberately did use the repo name in the head parameter, so it probably worked at that point.

[adamw]

Thanks for investigating this! I'm getting tens of emails every night for a couple of days now, because of failed steward actions. And I see that even a PR is there ❤️