Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Option "Changes without a pull request" has no effect for master in "Project Settings"

Alexander September 9, 2019

I would like to allow pushing without pull request to master for one user/host (the SSH key is configured in the BitBucket). For this purpose I go to the "branch permissions" in the "Project Settings" (because I want to configure it globally, for any repo of the project):

Screenshot from 2019-09-09 14-07-45 (copy).png

I tested this way perfectly for "release/*" branches, but for some reason it does not work for master. I get the error message when I attempt direct push:

    remote: Branch refs/heads/master can only be modified through pull requests.
    remote: Check your branch permissions configuration with the project administrator.

As a workaround I have to do this in the "branch permissions" of the repo in the "Repository settings" like this:


Screenshot from 2019-09-09 14-08-38 (another copy).png

On the last picture it is clearly visible that the "Project Settings" are already inherited, thus from the healthy logic there should be no sense to duplicate the same setting in the "Repository Settings", which is especially weird that for "release/*" it works without it.


So the workaround works.. But I don't want to do it for each repo! I find it pretty straightforward that if it works for a normal branches then it must work for master as well.

Otherwise it must be clearly explained in the documentation what is the reason of the restriction.
However I checked this guide https://confluence.atlassian.com/bitbucketserver/using-branch-permissions-776639807.html and I did not find any mentioning that for master the behavior is different.

I am now thinking about submitting a bug. I would appreciate if someone confirms it is is a bug or not or refer the proper documentation where this behavior is described as expected.

1 answer

0 votes
Alexander September 11, 2019

After some troubleshooting with the help of sysadmin colleagues we found that this strange behavior was caused by a configuration fault.

The problem was that on the build machine where the SSH access key is stored the line "IdentityFile ~/.ssh/id_rsa" was *commented* in the ~/.ssh/config file. We found that the id_rsa was rejected only when we set GIT_TRACE environment variable to 2 and tested the displayed ssh command manually.

It seems that after the key was rejected it tried another one that was read-only and this produces the misleading message which made me to think that the BitBucket settings don't work. I did not investigate why it worked for release/* branches despite this, but I am satisfied that the main cause is found.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events