gh pr merge $pr_number --auto --merge fails if a required status check has failed.

Describe the feature or problem you’d like to solve

Say my pull request has 3 required status checks; one of them has already passed, one is currently running and one has failed.
I run this command -
gh pr merge $pr_number --auto --merge

This command fails with this error -
GraphQL: Required status check "check name" is failing. (mergePullRequest)

When I'm enabling auto-merge on a pull request, my intention is to automatically merge the PR when all required status checks pass; emphasis on "automatically merge". In the above example, I would've expected the auto-merge to be enabled on the PR, irrespective of the current status of the status checks. The PR won't be merged, but auto-merged should've been enabled, so that when the cause of the failed status check is fixed, the status check passes and the PR gets automatically merged.

Proposed solution

Enable auto-merge irrespective of the current status of the status checks.
If the auto-merge is not enabled because a status check is "failed", then the user will have to manually merge it later.
This also has potential of breaking CIs.

Huh...!! I'm checking more of my different CI job logs and I see the above behavior has happened only in one job while the auto-merge was enabled for other pull requests even when they too had one status check failure.

I thought this might've been due to race-condition between the two jobs (status check job and the job that enables auto-merge). So, I manually ran the command on a PR which currently has a failed status check and it still enabled the auto-merge. 🤷🏼‍♂️

So now I'm wondering why did it fail in that one job with the error msg clearly saying it failed because the other status check has failed!

@bikram-agarwal

Hi @bikram-agarwal, thanks for raising this and sorry you're running into issues. Is it possible for you to reproduce this, and if so can you show us the output with GH_DEBUG=api?

Looking at the code I can only imagine one way that the CLI might have lead to this failure.

We fetch the state of the PR here:

cli/pkg/cmd/pr/merge/merge.go

Line 488 in 08bc4cb

pr, baseRepo, err := opts.Finder.Find(findOptions)

Then we set autoMerge if you've provided the flag and it's not immediately mergeable:

cli/pkg/cmd/pr/merge/merge.go

Line 508 in 08bc4cb

    
           autoMerge:          opts.AutoMergeEnable && !isImmediatelyMergeable(pr.MergeStateStatus),

This conditional just checks the PR status field:

cli/pkg/cmd/pr/merge/merge.go

Lines 742 to 743 in 08bc4cb

    
           switch status { 
        
           case MergeStateStatusClean, MergeStateStatusHasHooks, MergeStateStatusUnstable:

We then pass that field directly through as part of the merge payload:

cli/pkg/cmd/pr/merge/http.go

Lines 88 to 96 in 08bc4cb

    
           if payload.auto { 
        
           	var mutation struct { 
        
           		EnablePullRequestAutoMerge struct { 
        
           			ClientMutationId string 
        
           		} `graphql:"enablePullRequestAutoMerge(input: $input)"` 
        
           	} 
        
           	variables["input"] = EnablePullRequestAutoMergeInput{input} 
        
           	return gql.Mutate(payload.repo.RepoHost(), "PullRequestAutoMerge", &mutation, variables) 
        
           }

You can see that after sending that we exit and don't even try to merge the PR. However, your error indicates that we hit a mutation further down:

cli/pkg/cmd/pr/merge/http.go

Lines 98 to 103 in 08bc4cb

    
           var mutation struct { 
        
           	MergePullRequest struct { 
        
           		ClientMutationId string 
        
           	} `graphql:"mergePullRequest(input: $input)"` 
        
           } 
        
           return gql.Mutate(payload.repo.RepoHost(), "PullRequestMerge", &mutation, variables)

However, I can't find any reason why the platform would indicate that we are in one of those states (mergeable) and then later become unmergeable. That said, I can't speak for the platform's consistency here. It wouldn't be the first time it didn't behave as expected.

I think without further logs from GH_DEBUG=api on an error we will have difficult investigating this.

Just to double check, on your failed case are you absolutely sure that you provided the --auto flag correctly?

@bikram-agarwal

@bikram-agarwal : Can you confirm this is still a problem, or can it be closed? Have you been able to recreate the issue and capture debug logs?

Given Will's walkthrough and the error message you received, the GitHub GraphQL API return that error when trying to enable the auto merge on the PR.

Hi. Sorry about not responding here earlier.
I have been monitoring the output of my CI since going live, and we haven't had this issue again. I am unable to reproduce this issue. Guess it was just a one-time fluke caused by something unknown.
This issue can be closed.

Navigation Menu

Repository navigation

gh pr merge $pr_number --auto --merge fails if a required status check has failed. #8206

Describe the feature or problem you’d like to solve

Proposed solution

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	switch status {
	case MergeStateStatusClean, MergeStateStatusHasHooks, MergeStateStatusUnstable:

	if payload.auto {
	var mutation struct {
	EnablePullRequestAutoMerge struct {
	ClientMutationId string
	} `graphql:"enablePullRequestAutoMerge(input: $input)"`
	}
	variables["input"] = EnablePullRequestAutoMergeInput{input}
	return gql.Mutate(payload.repo.RepoHost(), "PullRequestAutoMerge", &mutation, variables)
	}

	var mutation struct {
	MergePullRequest struct {
	ClientMutationId string
	} `graphql:"mergePullRequest(input: $input)"`
	}
	return gql.Mutate(payload.repo.RepoHost(), "PullRequestMerge", &mutation, variables)

gh pr merge $pr_number --auto --merge fails if a required status check has failed. #8206

Description

Describe the feature or problem you’d like to solve

Proposed solution

Activity

Bikram-DoorDash commented on Oct 17, 2023

williammartin commented on Oct 24, 2023

williammartin commented on Oct 24, 2023

andyfeller commented on Nov 20, 2023

Bikram-DoorDash commented on Nov 20, 2023

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions