Thanks for the pull request, I thought I tested this workflow correctly.

My initial expectation is that this param mergewhenpipelinesucceed as explained here

merge_when_pipeline_succeeds boolean If true, the merge request is set to auto-merge.

Would disable or enable the automate merge request where having it to nil delegate the default behavior to GitLab, but apparently I was wrong.

I like your approach as it aligns with the GitHub parameters enable and it's very obvious code wise

This change modifies the default behavior for GitLab by disabling auto-merge unless explicitly enabled.
Although it differs from the previous default, it now aligns GitLab behavior with GitHub and provides users more control.

The GitLab auto merge feature was introduced in the last release, and it was an unintended behavior change so I am not considering this more bug than a feature

Would disable or enable the automate merge request where having it to nil delegate the default behavior to GitLab, but apparently I was wrong.

When I tried to use this to disable or enable auto-merge, I got:
"set auto-merge on GitLab merge request: PUT … {message: 405 Method Not Allowed}".

So if you have a pipeline on the MR, you must set merge_when_pipeline_succeeds: true. (Or you need to disable auto-merge in some other way.)

I also tried using assignees and reviewers, but my MRs were merged automatically no matter what.

I wondering if we should remove this setting "merge_when_pipeline_succeeds" by default at least not expose it to Updatecli enduser

I wondering if we should remove this setting "merge_when_pipeline_succeeds" by default at least not expose it to Updatecli enduser

GitLab allows auto merge, but it can be affected by various policies. If you take a regular MR, in some cases it can be merged immediately, merged automatically if the pipeline succeeds, or merged regardless of anything. I think it's better to have "merge_when_pipeline_succeeds" than not to have it.