MergeRequest API 's merge_when_build_succeeds not work?
Summary
I don't known it is a bug or I misunderstand the api.
The accept merge api of MergeRequest says:
merge_when_build_succeeds
if true the MR is merged when the build succeeds
But when I use this api in build process, it always return 405 Method Not Allowed
Am i wrong use this API ? From my understand, use this API will cause the result that just like click the
Steps to reproduce
use this api when build in process. demo yml file
the py file
Expected behavior
api work and mark this mr can be merged when build success.
Actual behavior
always return {"message":"405 Method Not Allowed"}
Activity
@markglenfletcher Sorry to mention you . Please have a look at this
@grzesiek Help!
😢 
Hi @yanceywang Does downcasing the boolean help? The following request worked for me:
curl -v -H "Content-Type: application/json" \ -H "PRIVATE-TOKEN: PRIVATE_TOKEN" \ -X PUT \ --data '{ "merge_when_build_succeeds": true }' \ https://example.gitlab.com/api/v3/projects/:project_id/merge_requests/:mr_id/merge@markglenfletcher Thanks for your reply. Try it again..Still not work
😢 When the pipeline is
running, I run this in terminal.curl -v -H "Content-Type: application/json" \ -H "PRIVATE-TOKEN: XXXXXX" \ -X PUT \ --data '{ "merge_when_build_succeeds": true }' \ http://XXX.XXX.com/api/v3/projects/6/merge_requests/116/merge * Trying 10.66.73.10... * Connected to XXX.XXXX.com (10.66.73.10) port 80 (#0) > PUT /api/v3/projects/6/merge_requests/116/merge HTTP/1.1 > Host: XXX.XXXXi.com > User-Agent: curl/7.49.1 > Accept: */* > Content-Type: application/json > PRIVATE-TOKEN: XXXXXXX > Content-Length: 37 > * upload completely sent off: 37 out of 37 bytes < HTTP/1.1 405 Method Not Allowed < Server: nginx < Date: Mon, 16 Jan 2017 11:58:29 GMT < Content-Type: application/json < Content-Length: 36 < Connection: keep-alive < Cache-Control: no-cache < Vary: Origin < X-Request-Id: 112eb7b9-48f8-439a-94d4-c2b8758474bc < X-Runtime: 0.090891 < * Connection #0 to host XXX.XXXX.com left intact {"message":"405 Method Not Allowed"}%Edited by username-removed-865582-
@yanceywang Which version of GitLab are you running? My test was against GitLab.com running v8.15.4
@markglenfletcher I use latest gitlab v8.15.4 too on my own server
And I checked this in my project, does this matter?
Edited by username-removed-865582I can confirm that the issue is related to the feature in project config displayed above by @yanceywang (Thanks by the way, you spared me a lot of trouble after two hours of trying different calls).
I think this is a bug, we should be able to setup automated merge after build is successful even if that config is checked
@ezzarghili So you met this problem too right? Any idea on how to solve this problem? My workaround is to forward merge request to another server in the last step of my pipeline, and delay 1s to use gitlab api to merge..
😟 @yanceywang at this point I just unchecked the feature in the project we have a handful developers in this project so we can live with it for now
a second option (to avoid having a second server) is to create a build project in gitlab itself trigger it at the last step see [Build Triggers API](gitlab https://docs.gitlab.com/ce/ci/triggers/)
also you can create a branch in the same project named (for instance) trigger and push to it at the end of the build then create a build stage for it
only: - triggerand for other stages
except: - triggerI hope this helps
-
@yanceywang @ezzarghili Thank you for the updates. Currently, for your configuration (only allow MRs to be merged when the build succeeds enabled), you will only be able to call the
merge_requests/:mr_id/mergeendpoint once the build has succeeded. Regardless of the value of themerge_when_build_succeedsparameter, if the build is still ongoing you'll get the 405 error.Is your proposal to be allowed to set the MR to
merge_when_build_succeedsvia an update call to the merge request whilst the build is ongoing? @markglenfletcher yes, that's the behavior I was expecting when I used the API
-
@grzesiek Do you think that it should be possible to update the
merge_when_build_succeedsflag via an update call for the Merge Request in this case, rather than the via themergeendpoint? 
@markglenfletcher Not sure what would be best. We already have
PUT /projects/:id/merge_requests/:merge_request_id/cancel_merge_when_build_succeeds, maybe we should have separateset_merge_when_build_succeeds?@grzesiek Thank you for your reply. This
merge_when_build_succeedsparam is really confusing。Since there is a feature
As I know, when only allow MRs to be merged when the build succeeds enabled, this feature is still work, so why there is no corresponding API for this?mentioned in issue #31183 (closed)
This could be related to this issue https://gitlab.com/gitlab-org/gitlab-ce/issues/22740 fixed with https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/10873
moved to gitlab#7806
Hey!
👋 GitLab is moving all development for both GitLab Community Edition and Enterprise Edition into a single codebase. The current
gitlab-cerepository will become a read-only mirror, without any proprietary code. All development is moved to the currentgitlab-eerepository, which we will rename to justgitlabin the coming weeks. As part of this migration, issues will be moved to the currentgitlab-eeproject.If you have any questions about all of this, please ask them in our dedicated FAQ issue.
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855You can also find more information here:
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304- https://about.gitlab.com/2019/08/23/a-single-codebase-for-gitlab-community-and-enterprise-edition/
Frequently Asked Questions
For an up to date list of questions and answers, please take a look at
https://gitlab.com/gitlab-org/gitlab-ee/issues/13855What will we do with the repository names?
https://gitlab.com/gitlab-org/gitlab-ee/ will become https://gitlab.com/gitlab-org/gitlab, and https://gitlab.com/gitlab-org/gitlab-ce will become https://gitlab.com/gitlab-org/gitlab-foss.
Why rename gitlab-ce to gitlab-foss?
Using "gitlab" and "gitlab-ce" would be confusing, so we decided to rename gitlab-ce to gitlab-foss to make the purpose of this FOSS repository more clear
I created a merge requests for CE, and this got closed. What do I need to do?
You will need to create a merge request at https://gitlab.com/gitlab-org/gitlab-ee/. This link will eventually redirect to https://gitlab.com/gitlab-org/gitlab.
How does the licensing work in this new setup?
Everything in the
ee/directory is proprietary. Everything else is free and open source software. If your merge request does not change anything in theee/directory, the process of contributing changes is the same as when using the gitlab-ce repository.Will you accept merge requests on the gitlab-ce/gitlab-foss project after it has been renamed?
No. Merge requests submitted to this project will be closed automatically.
Will I still be able to view old issues and merge requests in gitlab-ce/gitlab-foss?
Yes.
How will this affect users of GitLab CE using Omnibus?
No changes will be necessary, as the packages built remain the same.
How will this affect users of GitLab CE that build from source?
Once the project has been renamed, you will need to change your Git remotes to use this new URL. GitLab will take care of redirecting Git operations so there is no hard deadline, but we recommend doing this as soon as the projects have been renamed.
Where can I see a timeline of the remaining steps?
https://gitlab.com/gitlab-org/gitlab-ee/issues/13304Will community contributions submitted to the new "gitlab" repository be available in the new gitlab-foss repository?
Yes, these changes will be synced to gitlab-foss automatically, several times per day.
