`spr land` in a repo with protected main branch?

[leebyron]

Trying spr in a project with a protected main branch that requires PRs results in spr land failing.

Any thoughts on how to circumvent this restriction?

[sven-of-cord]

I'm not sure I understand. Can you provide more details and/or copy-paste the error message? We have branch protection on as well and require PRs, and have no problems landing with spr.

[leebyron]

This could be some other esoteric issue with Github.

When attempting to spr land, it fails printing "Merge attempt failed. Changes must be made through a pull request".

Of course, the branch up on Github is frontend by a pull request. Once spr failed to merge this from the command line I tried merging from Github's web UI by pressing the "Merge" button, I got the same exact error within the UI:

I ended up having to temporarily disable branch protection to land this.

Since this is happening also on Github, it may be a Github specific issue. However, is there anything about how spr does the branch set up or pull requests creation that might be non-traditional to cause Github to be confused about it's state as a valid PR?

[sven-of-cord]

I am puzzled and intrigued.

This is the branch protection rule for the master branch in this repository: There are no branch protection rules for any other branches in this repository. With this configuration, I have no problems using spr land for merging.

I'm wondering if your configuration is stricter in some way.

Does this problem occur with single PRs (those that are created targeting your main branch), or PRs that are based on other unlanded changes (those for which spr creates a synthetic base branch). Or both?

[leebyron]

My branch protection is actually less strict (for now). Our primary branch is main rather than master but otherwise I see no significant differences here.

Does this problem occur with single PRs (those that are created targeting your main branch), or PRs that are based on other unlanded changes (those for which spr creates a synthetic base branch). Or both?

This particular case was the first in a stack, so was not based on unlanded changes. I have not yet tested other scenarios in this particular repo yet

[tstirrat]

Seeing the same issue here with branch protection:

It is the first of two stacked PRs, we have branch protection on master

[rockwotj]

This is certainly a github bug but if I update the base branch in their UI to be master (even for the first PR in a stack that should already be master) spr land then works.