Failed merge-request


I am new here and wondering how to make MR in correct way. Unfortunately the interface of GitLab not so intuitive and friendly to give a glue about error root cause.
My MR failure : Pipeline · Arkady Gilinsky / wireshark · GitLab
According to my understanding I should edit MR and enable “Allow commits from members who can merge to the target branch” option, but this option is not interactive, i.e. it can not be enabled on page of MR. Simply the checkbox is not clickable.
I would appreciate any help or assistance on the issue.

Thanks in advance.

I’ve never heard of this setting before, but if I look at one of my MRs for a repo I don’t “own”, I see that if I edit the MR (by clicking the Edit button on the top-right of the MR overview page), there’s a checkbox right at the bottom of the form.

There is some documentation for the option here.



I also see this checkbox, but the issue is that it not clickable and ‘Disabled’ by default.
From other side it’s default value (Disabled) leads to failure in one of the MR stages, so I can not proceed further.

I am getting negative user experience while working with GitLab. Sometimes certificates not corresponds to the URL and I am getting warning about this from my browser, sometimes getting 500 error while accessing to some internal page and in addition the issue with MR :rage:

@ark-g there is currently ongoing issue with see
Everyone gets same errors now. :frowning:

You should get a reason why is the checkbox disabled right below.
My guess would be you have “Not available for protected branches” there. Since your MR is from ark-g:master into wireshark:master and best practice is to create MRs from feature/bug branches.

As I can see it, you have to close that MR, create new branch in your fork, commit the changes to that new branch and create a new MR from that new branch into wireshark:master. In this case the checkbox should be enabled and checked by default.

Also don’t forget to add access to upstream developers as described in the docs @snim2 linked.

1 Like

Thanks for your advice, you are lifesaver.
I did MR from other branch, as you recommended, and the needed checkbox was marked by default, so I didn’t need to make this click.
Could you, please, clarify, what should I do further?
There are two buttons:

  • “Approve” : this is for core developers, but I can approve for some strange reason (I am not core developer. It is possible in the future, but not now :slight_smile:), i.e. button is clickable. What should I do with it ?
  • “Rebase” : probably for final rebase operation, I assume.
  1. I would expect that your detailed explanation will be under this problematic checkbox, since neither existing explanation nor link do not clarify steps to fix the issue.
  2. In general I do not see any difference why it should matter from where I do my MR - from master or from my-crazy-fix branch :thinking:

Anyway, thanks again, the checks did passed and it looks much better.

Create MR from dedicated branch is best practice, because it is often the case that (mostly regular) contributors are working on several features or bugs at the same time. Having it in separate branch avoid mixing changes for several things in commits. It is easier to review, since you are changing only stuff for one particular thing and it is easier to test, because you don’t have to test everything with each commit. You can find many (mostly the bigger) teams maintaining open source software code, on GitLab or other providers, to follow this best practice and rejecting change requests from fork’s default branch.

Next step would be from the upstream developers, they should review your MR and point if something is missing or needs to be changed.
I guess the upstream project is not using “Approvals” so you can ignore that button.
You can rebase your branch with the changes from upstream master if needed. But this is usually described in “” or similar files where it is described what is the process.