Send status updates to hosted GitLab instances

Since BuddyBuild is shutting down for Android users, and all other parties don’t work with Gitlab this feature could set you apart from the competition


Got it, thanks for the bump @bartjo!

Note: self hosted GitLab should work in general on except the build status sending, which is only available for

Would there be a way to manually do it using steps in the workflow ?


Does your recent introduction of outgoing webhooks ( solve this issue?


Sure, it’s definitely possible. The only thing you can’t report via a step is if the build is aborted before the step would run.

We don’t have a step for this yet. I added it to our list, but if anyone would have the time to get started on it we’re always happy to help! Related docs:

You can also find an example step which does exactly this, reports the build status, just for GitHub (both hosted and self-hosted) instead of for GitLab:

Not directly. The outgoing webhook sends data in its own format, you have to convert that with your own server/service to GitLab specific format otherwise GitLab won’t accept it.

Update / note: you can find the related docs at

There’s even a curl example there - you can drop that into a Script step.

curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" ""

We’ll try to work on a related Step ASAP but can’t promise any ETA right now.

Hey guys,

Thanks for the official build status.

Thanks for making Bitrise awesome!

1 Like

Glad to hear you like it @ClementAppsolute ! :wink:

Are you going to implement this for GitLab instances specifically? Would be awesome to have this for e.g. BitBucket Server as well :slight_smile:
Or would this require an additional feature request?

Thank you @viktorbenei for the curl example. I’ve further investigated the possibilities and this is our working script step at the moment:

    - script:
        title: Report Build Status to GitLab
        - content: |-
            #!/usr/bin/env bash
            if [ $BITRISE_BUILD_STATUS == "0" ]; then

            curl --request POST --header "PRIVATE-TOKEN: $GITLAB_PRIVATE_KEY" "https://$GITLAB_CUSTOM_DOMAIN/api/v4/projects/$GITLAB_PROJECT_ID/statuses/$GIT_CLONE_COMMIT_HASH?state=$GITLAB_BUILD_STATE&target_url=$BITRISE_BUILD_URL&name=Bitrise-CI"
        is_always_run: true

You can just copy and paste the step to your bitrise.yml file and add the following ENV variables:

The domain of your hosted GitLab instance – without https:// – e.g.

A personal access token with API checkmark checked – the account must have access to the project – see here on how to get such a token. Looks something like this: 9koXpg98eAheJpvBs5tK .

The project ID which you can find by going into your projects “Settings” > “General” page and expand the “General project settings”. Here’s a screenshot:

The bad news is that this script step can only report success and failed state to GitLab. pending or running states would be great as well, but I don’t know if this is even possible with this method.

Still, better than nothing, right? :tada:

Additionally, you may want to set the following option in your project settings:

Then your merge requests will look something like this when Bitrise CI fails (note the disabled Merge button):

Please note that we came across an issue with the above solution – once the example Merge Request passed on Bitrise CI, the Merge Request still was not mergable. This might be an issue with GitLab, maybe. In any case, this is what it looks like now:

When we look at the Merge Request from the list of Merge Requests you can see though, that the successful state was correctly reported to GitLab:

Therefore we had to uncheck the Only allow merge requests to be merged if the pipeline succeeds option for now. I linked this thread on the related GitLab issue page here.

Thanks for all the info & screenshots @jamitlabs, we really appreciate it!!

Quick question, did you try to use our GitLab status step (

@MartinStraub when we get to work on the built in support (meaning to do it without any Build Step) we’ll definitely support the self-hosted versions of the “big three” (GitHub, Bitbucket, GitLab).

Might take a bit more time for Bitbucket as the self hosted version of Bitbucket (Bitbucket Server) is quite a bit different compared to, in fact it wasn’t even called Bitbucket initially, it was Atlassian Stash (, and even to this day these have separate API, webhook etc. formats, while GitHub and GitLab self-hosted have the same API & other formats as the .com hosted versions.

In any case, a step for Bitbucket Server is definitely possible, similar to the existing GitHub Status ( and GitLab Status ( steps. You can create a step if you have some time, it’s quite simple - a related recent blog post:

I didn’t know that existed. Why wasn’t the link posted earlier in this thread, it’s exactly matching the topic! :smiley:

Nevermind, I’ll try it out and replace the entire stuff I mentioned above with it if it works. One question about it (I can’t find documentation on the Repo): How am I supposed to configure the step to send “pending” and “running” states correctly? “Running” could probably be established by placing the step into my workflow twice, one at the beginning and one at the end. But what about “pending”?

Well I just put the step at the beginning and end of my workflow. When it run at the beginning, the step passed successfully (green state with a checkmark) but I couldn’t find the “running” state anywhere in GitLab. I’d expect a “Running 1” here in this screenshot:

I’ll update you on the step at the end once the build has finished…

Here’s the entire step output:

- PrivateToken: abcdefg
- RepositoryURL:
- CommitHash: someHash
- PresetStatus: auto
|                                                                              |
| ✓ | gitlab-status                                                 | 7.79 sec |

UPDATE: The step at the end didn’t work either. It passes but there’s nothing on GitLab.

If you want to report anything else other than “success/error” please set it in the step. As mentioned in the input’s description ( ) :

Set Specific Status: If set, this step will set a specific status instead of reporting the current build status. If you select auto the step will send success status if the current build status is success (no step failed previously) and failed status if the build previously failed.

Meaning, with the default auto option the step will report either success or failed based on whether the build failed or not up to that point. It will not report “pending” or anything else, as it has no idea whether the step is the first or last step in the workflow. It can only know/detect whether a previous step failed or not, but can’t tell whether there will be 10+ other steps after it or 0.

Can you please create a #issues:steps-and-tool-issues report for this? Might be a configuration issue, or an actual step bug. Please don’t forget to include the related build’s URL! :wink:

Hi everybody,

Thank you for requesting a feature.
I’m pleased to inform you that the feature is implemented and it’s already released. :champagne::sunglasses:
You can find more information in our blogpost:
…and on our devcenter: