Repository navigation
Support rebase_in_progress #1775
Description
Description of the problem, including code/CLI snippet
Rebase operation (via gitlab) is asynchronous so if for example you want to do merge afterwards there is no way if rebase is finished or not.
mr.rebase ()
# somehow wait for rebase🤔
mr.merge ()
Expected Behavior
Possibility to check if rebase is in progress which is supported by gitlab api (see include_rebase_in_progress in https://docs.gitlab.com/ee/api/merge_requests.html)
Actual Behavior
No way to check rebase in progress, having to rely on crude timers and so on.
I can see that in #823 it was specially left out but would it possible to support it maybe via separate function which does a request again and returns only this field maybe?
The other way is support rebase & merge operation as one but it might be not very flexible approach since error may happen during rebase &c.
Activity
nejch commentedon Dec 23, 2021
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?
nejch commentedon Dec 23, 2021
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
JohnVillalovos commentedon Dec 23, 2021
I may not understand all of this but you should be able to do:
But I did not test it so it may not work.
nejch commentedon Dec 23, 2021
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.JohnVillalovos commentedon Dec 23, 2021
I wasn't sure if @Predelnik was aware that they could pass the
include_rebase_in_progressargument 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.
Predelnik commentedon Dec 23, 2021
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 & mergeas a single operation (issue link) , then it will probably be available through api.JohnVillalovos commentedon Dec 23, 2021
Please let us know if it works or not. Спасибо
chore: add and document optional parameters for get MR
Predelnik commentedon Dec 23, 2021
Yes seems to work fine. Thank you!
JohnVillalovos commentedon Dec 23, 2021
Great. I've created an MR to add some docs here: #1776