In my buddybuild configuration there is a nice feature: whenever I create a Merge Request on GitLab a new build is triggered on BuddyBuild (that’s easy to achieve with bitrise too) and the Merge Request shows a link to the build as “pipeline” and the Merge buttons switches to “Merge when pipeline succeeds” (see attached picture).
That’s really cool and it’s something I’m trying to achieve with Bitrise as well.
Is there any way you can help me with this matter?
I’ve been trying different configurations of webhooks but with no success.
Got it - for self hosted GitLab right now we don’t have a built in status report, but you can use the new GitLab Status reporter step ( GitLab status step v0.9.0 released ) to send back the build’s status to any (including self hosted) GitLab instance.
Let me know how it goes or if you’d have any questions!
That looks like the one, thanks, but I can’t get it to work!
Most likely some mistaken configuration: it complains about the missing commit’s hash but I’m not sure what it expects there.
You should add it as the last step to the build @Wolf, as it will report the build’s status when it runs. So if you run it e.g. before your tests, it’ll report the status before the tests, and if the tests fail it won’t report that error. If you add it as the last step in the workflow then it’ll report the status at the very end, including all previous steps
Ah, now I got how it works!
So the status says something about the pipeline basically reporting if it was successful or if any errors occurred, but it doesn’t show anything while it’s running the job and it can’t directly set and update that “merge when pipeline succeed” button, is that right?
Anyway, I moved it to the bottom of the steps list but it stil complains about the missing commit hash. All the other steps succeeded.
Right now the value is $BITRISE_GIT_COMMIT, same value used in the “Git clone repository step”'s configuration so I guess it has a value…
ah sorry, didn’t see your last message, my bad.
So if I got it right that’s happening only because I’m running the build manually, not as a result of a trigger.
I’ll try to setup a trigger then, let’s see how it goes in that case
I think that’s not an independent functionality, if the CI system reports “success” for the build gitlab will auto merge it. I might be wrong, but AFAIK that’s how it works. Maybe a “in progress” report is also required… In that case you can add a second step to the very start of the build, and set it to report pending or running right when the build starts (https://github.com/bitrise-steplib/steps-gitlab-status/blob/a1c84e8b375d84c4fb42729325ac1d0f94dbc607/step.yml#L62).
Exactly. A git commit hash is required for status reporting, and that’s only passed from the bitrise.io server to the builder if the build is triggered via a webhook OR you specify the commit when you manually start the build (switch to Advanced mode in the build start popup → you can set the commit there).
Yeah, I got it to work!
It was not working because I set a wrong value in the status field, I didn’t notice the description that explicitly told what values to use
We released a new version for GitLab status step (0.9.2). We made the step skippable, which means the step not failing anymore if the commit hash is not specified, but shows a warning message: “GitLab requires a commit hash for build status reporting”.
there seems to be an issue with the latest version of the plugin (0.95), it doesn’t update the pipeline status anymore on our instance of Gitlab.
Most likely it’s something that happened on version 0.93, that has the most relevant changes, 0.94/95 are pretty small releases. Version 0.92 works like a charm.
The error is a 404, but my guess is that is sending the wrong request to the API endpoint.
We took a look on the gitlab logs and those 404 don’t show up.
