Have option for Marge to automatically remove WIP status of branches to merge

[trickl]

By default, branches named "wip_" will get rejected by Marge as the merge request that is generated will start with "wip" and be marked in progress.

https://docs.gitlab.com/ce/user/project/merge_requests/work_in_progress_merge_requests.html

Typically developers will work on a development branch and label it as "wip_" to distinguish it from production branches, then decide to Marge it - in which case they will expect Marge to remove the WIP tag. Presently, their work flow would have to be:

1. Create development branch (wip...)
2. Submit MR
3. Watch MR get rejected unexpected by Marge as its WIP.
4. Rename their branch after figuring out the problem.
5. Resubmit

This is less than ideal and could be solved if Marge automatically removed the WIP tag. As some teams might actually want this protection in place, I would make it an optional setting of Marge so teams can decide the behaviour they want.

[jcpetruzza]

Ok, some minor clarifications:

• In GitLab, if the title of the merge request starts with "WIP", then the MR is considered work-in-progress and it is not possible to merge it (neither using the Merge button nor the REST Api) until this is resolved by editing the title and removing the "WIP" part. I.e., you don't need to rename your branch to resolve this.
• GitLab also added a feature where if the branch you use to create the merge request starts with wip_, then it marks the merge request as work-in-progress, which you resolve, again removing the WIP from the title. The same will happen if you push a fixup commit.
• At the moment, when marge picks a merge request to process, it first checks if it is marked as WIP by gitlab and in that case it bails out immediately leaving a message about it. The rationale is that you don't want to wait until CI passes to find out that you can't merge the branch.
• So, from the point of view of marge the name of the branch is irrelevant, the only thing that matters is whether the merge request that was assigned to her is currently marked as WIP or not.

We could make it so that, when ran with a certain flag, marge will simply edit the title to remove the WIP tag and then just merge the request. It would be a relatively simple fix. But I wonder if this would be a sane setting: the WIP is a protection that is there in order to prevent someone to merge a branch that the author thought was not ready. Developers opt-in to this feature by prefixing their branches with wip_ or by putting WIP on the title of their MR. If one were to run marge with this flag, individual developers could no longer opt to use it, since marge will just ignore.

However, I wonder if the annoying bit here is that a long time may happen between you assign the request to marge and you get the notification saying "can't merge, the branch is WIP", since other requests may have to be merged before this happens. And, again, once you react, you need to wait until your branch gets to be merged again. So maybe having marge continuously polling branches assigned to her and unassigning herself immediately in case the branch is WIP would be a good enough behaviour? What do you think?

[trickl]

Thanks for the response. Agree with point 1. Regarding the second point, I'm not sure that is correct, or at least I cannot find any documentation supporting that claim. My understanding is that it is when Marge suggests a title for the merge request that contains multiple commits, it uses the branch name. As such, if the developer uses the default template for the merge request, the MR will be marked as work in progress as well. The association between branch name and merge request title is solely due to Marge.

…

On Wed, 29 Nov 2017 at 20:20, Daniel Gorín ***@***.***> wrote: Ok, some minor clarifications: - In GitLab, if the *title* of the merge request starts with "WIP", then the MR is considered work-in-progress and it is not possible to merge it (neither using the Merge button nor the REST Api) until this is resolved by editing the title and removing the "WIP" part. I.e., you don't need to rename your branch to resolve this. - GitLab also added a feature where if the branch you use to create the merge request starts with wip_, then it marks the merge request as work-in-progress, which you resolve, again removing the WIP from the title. The same will happen if you push a fixup commit. - At the moment, when marge picks a merge request to process, it first checks if it is marked as WIP by gitlab and in that case it bails out immediately leaving a message about it. The rationale is that you don't want to wait until CI passes to find out that you can't merge the branch. - So, from the point of view of marge the name of the branch is irrelevant, the only thing that matters is whether the merge request that was assigned to her is currently marked as WIP or not. We could make it so that, when ran with a certain flag, marge will simply edit the title to remove the WIP tag and then just merge the request. It would be a relatively simple fix. But I wonder if this would be a sane setting: the WIP is a protection that is there in order to prevent someone to merge a branch that the author thought was not ready. Developers opt-in to this feature by prefixing their branches with wip_ or by putting WIP on the title of their MR. If one were to run marge with this flag, individual developers could no longer opt to use it, since marge will just ignore. However, I wonder if the annoying bit here is that a long time may happen between you assign the request to marge and you get the notification saying "can't merge, the branch is WIP", since other requests may have to be merged before this happens. And, again, once you react, you need to wait until your branch gets to be merged again. So maybe having marge continuously polling branches assigned to her and unassigning herself immediately in case the branch is WIP would be a good enough behaviour? What do you think? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLl5VvLHhn9hL93EOkZzp_L78X9KMmgks5s7byegaJpZM4Qu3hC> .

[jcpetruzza]

I think you are correct... partly.

If the branch is called foo_bar_1234 and contains more than one commit, then gitlab will suggest foo bar 1234 as title for the merge request. Then you get as a not-sure-if-intended side effect that if your branch was called wip_foo_bar_1234, then the proposed title will be wip foo bar 1234 and if you just press "Create", your merge request will be marked as WIP (since the title starts with wip). It is true though that gitlab will automatically mark the MR as WIP if you later push additional fixup commits.

The association between branch name and merge request
title is solely due to Marge.

This part is definitely not the case. Marge has nothing to do with the creation of merge requests, that's all vanilla gitlab functionality. Everything that happens before you assign Marge's user to a merge request is outside of her domain.

[trickl]

I see, thanks

…

On 30 Nov 2017 00:19, "Daniel Gorín" ***@***.***> wrote: I think you are correct... partly. If the branch is called foo_bar_1234 and contains more than one commit, then *gitlab* will suggest foo bar 1234 as title for the merge request. Then you get as a not-sure-if-intended side effect that if your branch was called wip_foo_bar_1234, then the proposed title will be wip foo bar 1234 and if you just press "Create", your merge request will be marked as WIP (since the title starts with wip). It is true though that gitlab will automatically mark the MR as WIP if you later push additional fixup commits <https://gitlab.com/gitlab-org/gitlab-ce/issues/25036>. The association between branch name and merge request title is solely due to Marge. This part is definitely not the case. Marge has nothing to do with the creation of merge requests, that's all vanilla gitlab functionality. Everything that happens before you assign Marge's user to a merge request is outside of her domain. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#68 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABLl5SeOtWJzFkunPmNiMBjpx8te8zA1ks5s7fSHgaJpZM4Qu3hC> .

[jcpetruzza]

I'm closing this issue in favour of #69 which I think would solve the issue with a better UX. Feel free to reopen!