Skip to content
Snippets Groups Projects
New issue look: Off

Can't accept MR through API when option "Only allow merge requests to be merged if the build succeeds" is set

    • Closed (moved) Issue created by Rubén Dávila @rdavila

    Related Zendesk issue: https://gitlab.zendesk.com/agent/tickets/56989

    Hi

As part of an automation, we want to use the REST API to accept a merge request once the CI build passes. For this we issue a PUT request like the following:

http://xxx.example.com/api/v3/projects/413/merge_requests/459/merge?merge_when_build_succeeds=true

This works fine as long as the project is *not* marked as "Only allow merge requests to be merged if the build succeeds". When that options is on, we get a `405 - Method Not Allowed`. This looks very strange... are we doing something wrong?

We are running the latest stable version of gitlab.

Thanks! 
Daniel
    Hi Rubén,

Thanks for your message! With the information you provided, I think I've been able to track down why this is not working for us.

In order to reproduce, you need to set the project to `only_merge_when_build_succeeds = true` *and* have the CI pipeline running for that merge request. In that case, we get in the console:
 
mr.mergeable_ci_state? 
=> false 

And that explains why `merge_request.mergeable_state?` is false in [the code that handles the PUT request](https://gitlab.com/gitlab-org/gitlab-ee/blob/e33b0cbd0dfb10617a37ec5ce054fadb82c8631b/lib/api/merge_requests.rb#L190).

Of course, when the user passes `merge_when_build_succeeds` then this shouldn't verify if the build already succeeded, since what we want is to wait for it in the first place. The check should instead be something along the lines of:


not_allowed! unless merge_request.mergeable_state?(skip_ci_check: params[:merge_when_build_succeeds]) 
not_allowed! if merge_request.project.only_allow_merge_if_build_succeeds? and not params[:merge_when_build_succeeds] and not merge_requests.mergeable_ci_state? 

However, one then should be careful [here](https://gitlab.com/gitlab-org/gitlab-ee/blob/e33b0cbd0dfb10617a37ec5ce054fadb82c8631b/lib/api/merge_requests.rb#L203) or you risk a race condition where the build was running when the check is done above, but already done but failed at this point where it is decided whether to merge directly or wait. I hope what I say makes any sense :)

Anyway, the second issue here seems to be that the API currently appears not to be exposing `mergeable_ci_state` nor `head_pipeline_id`, so it is not easy to circumvent this issue. I mean, I don't see a simple and reliable way of programmatically merging when the build is finally green. I'm guessing we can try to find a pipeline for the MR's sha using the pipeline-api and poll on that. But from the docs, there seems to be no way to search a pipeline by commit id, so we would have to scan all the pages looking for the best candidate (which would could take very long if there is none) or, if they come sorted by time, pick the first occurrence and cut the search once the pipelines are too old. Am I missing something? Is there anything better we can do?

Thanks! 
Daniel

    /cc @DouweM @smcgivern mentioning you so you can prioritize and assign the proper person to fix it.

    Designs

      Child items ...

      2. Activity

      Please register or sign in to reply