Gitlab's Merge Request status not updated


I’m experiencing what’s described here :

A relevant link seems to be :

My understanding is that the ref attribute in Gitlab’s status API has a misleading name. In a MR context Drone seems to post the build status with a refs/merge-requests/*/head like ref, where Gitlab expects to find the name of the upstream branch instead.

Am I right ? And, who do you feel I should bug with this issue ?


The most common reason for the status not being updated is forgetting to properly configure the DRONE_HOST [1][2][3]. I am not aware of any known issues with the drone implementation.


DRONE_HOST is prorperly set in my docker-compose file (DRONE_HOST=https://drone.companyname.tld).

I’ve used the Gitlab’s Ruby CLI to fetch the pipelines objects as the reporter of the Gitlab issue did [1]. I’ve reviewed only a small subset, but the pipeline I found showing a status icon in the MR view was the one having a “ref: branch” like attribute. The other pipelines (“ref: refs/merge-requests/*/head” like) don’t show.


Yea, no clue. I am the primary author of drone, but I do not personally use gitlab. Our gitlab driver is community maintained, so if you think there is an issue I would recommend authoring a patch.

I was not on the right track.

In order to the get the pipeline status in the MR window, the forked repository has to be enabled in Drone too. If not, GitLab considers that CI is not active.

It’s kind of not obvious, because by default, a pipeline is executed in the context of the main repository, and its result not reported.

I have the same issue, still no workaround :|.

Hey :wave:. Were you able to resolve this? I followed and builds are being picked up just fine by drone, but, unfortunately, no status is displayed on gitlab side :-/ . Is there anything else I should do to make gitlab acknowledge drone?

I cannot find the thread, but someone researched this issue and indicated Drone may be using a deprecated API endpoint. See

This is not something I am able to investigate or work on at the moment due to conflicting priorities, so if someone wants to accelerate a solution I recommend testing and sending a patch to Otherwise, I should be able to take a look at this in ~6 weeks.

1 Like

Thanks for the information sharing