Thanks for the request @Predelnik. We often come to the topic of how much this library should do, and this seems to be a bit more than just wrapping the API calls. We've closed similar PRs before (e.g. #1443) because then it gets a bit blurry and we'd end up adding more and more features that aren't related to the API itself.

So my first thought is that this should be handled by user code, not in the core library. On the other hand everyone would be doing this, so maybe a convenience toolkit somewhere (if not necessarily in the core library), would make sense. I'll leave it open for now, @JohnVillalovos any thoughts?

But we should at least maybe document it the way we do for export (which is the same situation really):
https://python-gitlab.readthedocs.io/en/stable/gl_objects/projects.html#id3

I may not understand all of this but you should be able to do:

gl = gitlab.Gitlab(...)
project = gl.projects.get(SOME_PROJECT_ID)
merge_request = project.mergerequests.get(SOME_MR_ID, include_rebase_in_progress=True)
print(merge_request.rebase_in_progress)

But I did not test it so it may not work.

I may not understand all of this but you should be able to do:

gl = gitlab.Gitlab(...)
project = gl.projects.get(SOME_PROJECT_ID)
merge_request = project.mergerequests.get(SOME_MR_ID, include_rebase_in_progress=True)
print(merge_request.rebase_in_progress)

But I did not test it so it may not work.

Yeah, the more I think about it the more I feel this should be a custom rebase_and_merge() method in user code that looks similar to our export example.

Edit: alternatively we'd need to have a flag to make the rebase() method not return until the rebase is finished but that would then be the case for many other async gitlab operations.

I wasn't sure if @Predelnik was aware that they could pass the include_rebase_in_progress argument or not. As it isn't documented in our documentation or listed as an option in the code.

If they didn't know about it then maybe this information solves their problem. Unsure if they need a whole automatic thing that will sit there and wait. Personally I don't think that should be something that PG (python-gitlab) should do. Rather leave it to the consumer of the library to write the loop to wait for the status to change.

I wasn't aware of possibility to add include_rebase_in_progress=True, so if this works this should be enough for my case. As for inclusion in the library, example might indeed suffice.

Also, there is a chance GitLab might themselves add rebase & merge as a single operation (issue link) , then it will probably be available through api.

I wasn't aware of possibility to add include_rebase_in_progress=True, so if this works this should be enough for my case. As for inclusion in the library, example might indeed suffice.

Please let us know if it works or not. Спасибо

Yes seems to work fine. Thank you!

Yes seems to work fine. Thank you!

Great. I've created an MR to add some docs here: #1776