Send status updates to hosted GitLab instances

bartjo · January 9, 2018, 11:06am

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

viktorbenei · January 11, 2018, 12:22pm

Got it, thanks for the bump @bartjo!

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

raphaelmina · January 16, 2018, 8:36am

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

ClementAppsolute · January 16, 2018, 2:12pm

Does your recent introduction of outgoing webhooks (http://devcenter.bitrise.io/api/outgoing-webhooks/) solve this issue?

Thanks,

viktorbenei · January 16, 2018, 7:16pm

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: http://devcenter.bitrise.io/bitrise-cli/create-your-own-step/

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: https://github.com/bitrise-steplib/steps-github-status

viktorbenei · January 16, 2018, 7:17pm

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.

viktorbenei · January 20, 2018, 9:31am

Update / note: you can find the related docs at https://docs.gitlab.com/ce/api/commits.html#post-the-build-status-to-a-commit

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

curl --request POST --header "PRIVATE-TOKEN: 9koXpg98eAheJpvBs5tK" "https://gitlab.example.com/api/v4/projects/17/statuses/18f3e63d05582537db6d183d9d557be09e1f90c8?state=success"

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

ClementAppsolute · March 2, 2018, 9:51pm

Hey guys,

Thanks for the official build status.

Thanks for making Bitrise awesome!

viktorbenei · March 3, 2018, 10:08am

Glad to hear you like it @ClementAppsolute !

MartinStraub · March 7, 2018, 11:48am

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

cg1 · March 8, 2018, 2:08pm

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
        inputs:
        - content: |-
            #!/usr/bin/env bash
            if [ $BITRISE_BUILD_STATUS == "0" ]; then
              GITLAB_BUILD_STATE="success"
            else
              GITLAB_BUILD_STATE="failed"
            fi

            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:

GITLAB_CUSTOM_DOMAIN
The domain of your hosted GitLab instance – without https:// – e.g. gitlab.example.com.

GITLAB_PRIVATE_KEY
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 .

GITLAB_PROJECT_ID
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?

cg1 · March 8, 2018, 2:41pm

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):

cg1 · March 9, 2018, 10:25am

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.

viktorbenei · March 12, 2018, 5:43pm

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

Quick question, did you try to use our GitLab status step (https://github.com/bitrise-steplib/steps-gitlab-status)?

viktorbenei · March 12, 2018, 5:48pm

@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 bitbucket.org, in fact it wasn’t even called Bitbucket initially, it was Atlassian Stash (https://www.atlassian.com/blog/archives/atlassian-stash-enterprise-git-repository-management), 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 (https://github.com/bitrise-steplib/steps-github-status) and GitLab Status (https://github.com/bitrise-steplib/steps-gitlab-status) steps. You can create a step if you have some time, it’s quite simple - a related recent blog post: https://blog.bitrise.io/how-to-create-and-share-your-own-bitrise-step

cg1 · March 13, 2018, 8:17am

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

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”?

cg1 · March 13, 2018, 8:27am

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:

Config:
- APIURL: https://gitlab.example.com/api/v4
- PrivateToken: abcdefg
- RepositoryURL: git@gitlab.example.com/Customer/Project.git
- 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.

viktorbenei · March 13, 2018, 4:09pm

If you want to report anything else other than “success/error” please set it in the step. As mentioned in the input’s description ( https://github.com/bitrise-steplib/steps-gitlab-status/blob/920f7b1d320a2d5ccb99c48bc49a126a528420a2/step.yml#L55 ) :

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 bitrise.io URL!

norbert · August 17, 2018, 10:23am

Hi everybody,

Thank you for requesting a feature.
I’m pleased to inform you that the feature is implemented and it’s already released.
You can find more information in our blogpost: https://blog.bitrise.io/introducing-gitlab-self-hosted-support-for-organizations
…and on our devcenter: https://devcenter.bitrise.io/adding-a-new-app/self-hosted-gitlab/

viktorbenei · September 11, 2018, 3:39pm