Setup just at least two of N reviewers for PR workflow
Hello support,
we would like to manage the PR flow with Rhodecode.
While doing some tryouts, we setup a new group (composed by 8 users) which will be the default reviewer group for some repos.
However, we noticed that all the 8 users inside the group have to vote the PR.
In our scenario would be best that just at least two of the eight people could vote it.
Is this possible? How we can get that point?
Best regards,
Andrea
[tested on rhodecode version 4.10.6 EE ]
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Marcin Kuzminsk... on 30 Mar, 2018 02:42 PM
Hi Paolo,
in 4.11 series we introduced user group votes. if you upgrade you'll be able to define in default reviewers how many users from a group needs to vote for a approval from that group.
Best,
2 Posted by paolo.rubano on 04 Apr, 2018 07:34 AM
Hello Marcin,
that's perfect.
Has been added also a way to auto-close forked repo after server-side merge has been done?
Best regards,
Andrea
Support Staff 3 Posted by Marcin Kuzminsk... on 04 Apr, 2018 10:51 AM
Dear Paolo-
Can you explain what do you mean by auto-close forked repo?
Best,
4 Posted by paolo.rubano on 04 Apr, 2018 12:49 PM
Hello Marcin,
what I would like to know is if it is possible to safely auto-close the "source repo" after the pull request has been successfully server-side merged.
By adopting pull-request workflow we will have more and more forked repositories.
In order to keep things clean it could be useful to have a utility that closes the forked repository automatically.
Is this functionality available or, as usual, is something left up to the user?
Andrea
Support Staff 5 Posted by Marcin Kuzminsk... on 04 Apr, 2018 01:37 PM
Hi Paolo,
Ok now it's clear. Generally this is left to the user. We do have an option to automatically close a branch for mercurial repositories after a merge, but not a fork. This is left to the user. However prior to upcoming release if you remove a fork you'll lose a diff history of pull-request that is why we didn't come to this point. In next release, we'll cache and save to disk those, so it's going to be safe to remove source forks.
We'll keep that in mind for next releases to allow easier cleanup of forks.
6 Posted by paolo.rubano on 05 Apr, 2018 09:02 AM
Hi Marcin,
thanks for your feedback.
I am glad to have proposed something could be useful to improve next versions.
Best regards,
Andrea