<!--IssueSummary start--> <details> <summary> Everyone can contribute. [Help move this issue forward](https://handbook.gitlab.com/handbook/marketing/developer-relations/contributor-success/community-contributors-workflows/#contributor-links) while earning points, leveling up and collecting rewards. </summary> - [Close this issue](https://contributors.gitlab.com/manage-issue?action=close&projectId=278964&issueIid=32665) </details> <!--IssueSummary end--> ### Problem to solve Our [merge request API](https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr) hasn't been updated to support our [merge trains](https://docs.gitlab.com/ee/ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/) feature and public API support is lacking in Merge Train. This means, users cannot automate their workflow via API. Today, users can control via UI, which is manual operation. ### Intended users * [Sasha (Software Developer)](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/#sasha-software-developer) ### Further details We currently support merging immediately using the [Accept MR API endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr). We also support [merge when pipeline succeeds](https://docs.gitlab.com/ee/user/project/merge_requests/merge_when_pipeline_succeeds.html) using the same API mentioned above with an additional `merge_when_pipeline_succeeds: true` parameter. In its current state, making a request to the [Accept MR API endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr) with `merge_when_pipeline_succeeds: true` in a project that has merge trains enabled has the same effect as clicking the "Start merge train when pipeline succeeds" button in the UI. This is a bit confusing and not correct. ### Proposal Mirror the changes we made to our internal API in order to support merge trains: https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/28595. Instead of sending a request to the `/merge` endpoint with `merge_when_pipeline_succeeds: true`, the endpoint would instead accept a `auto_merge_strategy` parameter with any of the following value: - `merge_when_pipeline_succeeds` - `add_to_merge_train_when_pipeline_succeeds` If we go this route, we should also update the [Get single MR endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr) with a new property, `available_auto_merge_strategies`, which indicates what auto merge strategies are available. ### Permissions and Security There are no special considerations from a permissions/security standpoint. Existing permissions for who can merge / add to merge train should be respected. ### Documentation The section of our documentation that would be most affected by this change would be the [Accept MR API](https://docs.gitlab.com/ee/api/merge_requests.html#accept-mr). The [Get single MR endpoint](https://docs.gitlab.com/ee/api/merge_requests.html#get-single-mr) may also need to be updated, depending on our implementation. <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION --> *This page may contain information related to upcoming products, features and functionality. It is important to note that the information presented is for informational purposes only, so please do not rely on the information for purchasing or planning purposes. Just like with all projects, the items mentioned on the page are subject to change or delay, and the development, release, and timing of any products, features, or functionality remain at the sole discretion of GitLab Inc.* <!-- triage-serverless v3 PLEASE DO NOT REMOVE THIS SECTION -->